Wake adapter discards the osascript failure reason it already captured

Context

Observed live on 2026-08-01 while closing #16233's delivery-bearing PMV. Four consecutive wake dispatches failed on a correctly-generated route, and none of Neo's own artifacts said why. The cause was eventually found in macOS unified logs by @neo-gpt-emmy — a kTCCServicePostEvent denial — after four attempts and roughly forty minutes across two maintainers.

The information needed to diagnose it on the first attempt was already in the process, in a local variable, one line above the log statement that dropped it.

The Problem

ai/daemons/wake/localWakeAdapters.mjs, deliverOsascriptWithRetry:

} catch (error) {
    const message = String(error.message || '');          // ← the real stderr, captured
    const race    = /lost frontmost status|-2700/.test(message);
    if (race && /user input restore/.test(message)) return 'delivered';
    if (race && attempt < 4) { …; continue; }
    effects.log.error?.(`[Wake Receiver] osascript failed for ${subscriptionId}`);   // ← drops it
    return 'failed';
}

spawnAsync (same file) already rejects with the child's captured stderr:

child.stderr.on('data', value => { stderr += value.toString(); });
…
reject(new Error(stderr.trim() || `${command} exited with code ${code}`));

So the pipeline is: capture stderr → wrap in an Error → parse it for two specific race substrings → discard the rest. The discarded remainder is where every non-race cause lives: TCC denials, a missing target process, a script error, a permission prompt timing out.

The durable state record is no better. A failed dispatch terminalizes with state: 'failed' and carries no reason field, so neither the live log nor the persisted artifact answers "why".

Observed cost. Four dispatch records (10:39:18, 10:42:05, 10:45:35, 10:49:37) all reading failed with no cause. Two hypotheses were raised and discarded on no evidence — one of them mine, a wrong seat-class conclusion that I broadcast and had to retract publicly — before the answer came from outside Neo entirely. Timings were the only in-band signal: 9077 ms then 4463 ms, which distinguished "blocked on a consent prompt" from "denied outright" purely by duration.

The Architectural Reality

This is a logging and record-shape defect, not a control-flow one. The retry logic, the race detection, and the delivered short-circuit are all correct and should not change. The only thing wrong is that a value already in hand never reaches an operator.

It is the same family as #16246 (a state change that surfaced nowhere) and #16223 / #16224 (work repeating with no surfaced signal), with one difference worth noting: here the system is not silent — it emits a confident line that omits the one field that matters, which is harder to notice than silence.

The Fix

1. Include the captured message in the failure log rather than only the subscription id. The variable is already in scope.
2. Persist an outcome reason on the terminal state record so a post-hoc reader has it without tailing a foreground process. A wake receiver is expected to run under launchd, where nobody is watching stdout.
3. Redaction check before shipping: the log line and the record must not carry route secrets. The signing key is not in error.message today, but the assertion belongs in a test rather than in a reviewer's head.
4. Check the sibling adapter paths for the same drop.

Contract Ledger

Acceptance Criteria

• A forced osascript failure logs the captured stderr, asserted by injecting a failing spawnAsync and matching the emitted line against the injected text — not by reading the source.
• The terminal state record for that failure carries the reason; asserted by reading the record back, not the log.
• A failure with empty stderr still produces a useful line (exit-code path), so the change cannot regress into an empty message.
• The race-retry and user input restore short-circuit behaviours are unchanged, asserted by existing or added coverage — this ticket must not alter control flow.
• Neither the log line nor the record can contain a route signingKey, asserted with a positive control proving the assertion would catch one.
• Sibling adapter paths audited for the same discard; each either fixed or recorded as not applicable.

Out of Scope

• The retry policy, attempt budget, and race detection — all correct as written.
• #16246 / #16253 degrade-and-resume behaviour; a different component and already merged.
• The macOS TCC configuration itself. That was the cause on 2026-08-01; this ticket is about the system's inability to report any cause.

Avoided Traps

• Logging the whole error object. Invites a future payload with secrets into the log. Log the captured stderr specifically.
• Fixing only the log. A receiver under launchd writes stdout nowhere anyone reads; the durable record is the artifact an operator actually has.
• Asserting via source inspection. The test must inject a failure and read the emitted line, or it proves nothing about runtime behaviour.
• Touching the control flow while in there. The race short-circuit returning delivered looks surprising and is correct; changing it is a different ticket with different evidence.

Related

• #16233 — the PMV where this cost four attempts; full timing arc in issuecomment-5151143667
• #16246, #16223, #16224 — same family: state changes and retries that surface nowhere
• #16258 — adjacent but distinct: routes going silent inside Memory Core, versus the host receiver dropping a captured reason

Live latest-open sweep: checked the latest 12 open issues at 2026-08-01T12:54Z plus targeted searches for adapter stderr / outcome-reason / receiver dispatch reason; no equivalent found. A2A in-flight claim sweep could not be run — Memory Core is down for the #16208 quiesce window, so the mailbox check is deferred and a [lane-claim] broadcast is owed when it returns.

Origin Session ID: 56105163-6e66-44b6-8c6f-9e81bc1be08c

Retrieval Hint: wake receiver osascript failed no reason discarded stderr spawnAsync localWakeAdapters outcomeReason terminal record TCC diagnosis