Route Codex wake delivery through app-server adapter

Context

Operator escalation on 2026-06-13: after 4+ hours away, dozens of wake prompts landed while the active swarm produced one PR from four active agents. This ticket exists because the current Codex wake path can report successful delivery without producing reliable autonomous lane conversion.

V-B-A evidence from the live incident window:

• list_messages({status: 'unread'}) at turn start showed only one fresh unread item, so the user-visible [WAKE] stream and the Memory Core unread inbox are different observables.
• Memory Core healthcheck at 2026-06-13T06:53Z reported features.wake.daemonRunning: true, lastPulseAt: 2026-06-13T06:48:30.819Z, and gateState: disabled.
• manage_wake_subscription({action: 'list'}) showed active @neo-gpt subscription WAKE_SUB:7648b86c-2f1e-43a8-95a6-cc399f66a938 as harnessTarget: 'bridge-daemon', metadata {appName:'Codex', focusSeedKey:'r'}.
• The wake daemon log shows repeated successful Codex deliveries for that subscription, including 2026-06-13T02:33:51Z, 03:16:07Z, 03:20:30Z, 03:33:48Z, 03:48:12Z, 04:00:48Z, 04:08:00Z, 04:13:43Z, 04:17:55Z, 04:24:54Z, 04:51:53Z, 04:58:30Z, 05:39:19Z, 05:48:56Z, 06:13:08Z, and 06:27:45Z.
• ai/scripts/lifecycle/harnessRouting.mjs already maps GPT-family fresh-session routing to adapter: 'codex-app-server'.
• ai/scripts/lifecycle/resumeHarness.mjs already has a Codex app-server branch using codex debug app-server send-message-v2 <payload>.
• ai/daemons/wake/daemon.mjs still dispatches normal bridge-daemon wakes only through tmux, osascript, webhook, and test adapters; it has no codex-app-server branch.
• ai/mcp/server/memory-core/openapi.yaml currently exposes harnessTargetMetadata.adapter as osascript|tmux only, so agents cannot even reconfigure the active Codex subscription to the native adapter shape.

Release classification: ON Project 12 — P0 v13 harness-autonomy blocker surfaced by the operator during active agent-harness work.

Duplicate/freshness sweep:

• Live latest-open sweep: checked latest 20 open issues at 2026-06-13T06:54Z; no equivalent live implementation ticket found. Nearby open issues are different scope: #13012 is the current harness epic, #12612/#12633 are deferred liveness/cycle-state work, and #10777 is a stale historical family whose own latest GPT comment recommends a fresh implementation sub-ticket before branch work.
• A2A in-flight sweep: checked latest 30 inbox messages at 2026-06-13T06:54Z with status:'all'; no recent [lane-claim] / [lane-intent] overlaps this Codex wake-adapter scope.
• KB ticket sweep: Codex app-server wake adapter bridge-daemon ignored wake delivery ticket surfaced adjacent archived or older context (#10517, #10664, #11990, #11994) but no current exact implementation ticket for normal A2A wake delivery via Codex app-server.

The Problem

Codex has two contradictory wake truths today:

1. The architecture and resume path already acknowledge Codex app-server as the safer control plane.
2. The live A2A wake path for @neo-gpt is still GUI paste through bridge-daemon/osascript and a mutable focus seed.

That means wake delivery can be logged as successful while still relying on Codex Desktop UI focus, composer state, and active-thread behavior. In the live incident, repeated delivered wake prompts did not reliably convert into lifecycle execution. More rules telling agents to run /post-review-pickup have already failed as a class; the wake path needs a substrate-level delivery primitive that can start or steer a Codex turn through the native app-server surface.

This is narrower than the deferred post-v13 liveness ledger. It does not solve claimable-now computation or global external enforcement. It removes the proven Codex-specific transport gap first: normal A2A wake delivery has no app-server adapter even though the resume path does.

The Architectural Reality

• learn/agentos/decisions/0002-phase3-wake-substrate-standards-alignment.md defines Codex app-server as the native-control-plane example and names turn/start / turn/steer semantics.
• learn/agentos/wake-substrate/PersistentProcessManagement.md says Codex Desktop should be handled by codex debug app-server send-message-v2 in the wake-daemon adapter set, while also warning that an active route with stale heartbeat means the bridge can receive A2A but the watchdog lane may not be driving recovery.
• ai/scripts/lifecycle/resumeHarness.mjs contains the existing codex-app-server command-shape precedent and test hooks (CODEX_CLI_PATH, CODEX_APP_SERVER_MOCK).
• ai/daemons/wake/daemon.mjs owns normal GraphLog wake digest delivery and lacks that adapter branch.
• ai/services/memory-core/WakeSubscriptionService.mjs validates the subscription route metadata and exposes subscription state through the MCP tool.
• ai/mcp/server/memory-core/openapi.yaml is the MCP contract agents use to subscribe/update wake routes.

The Fix

Add a Codex app-server adapter for normal wake-daemon digest delivery, reusing the existing resumeHarness.mjs command-shape precedent where possible:

1. Extend the wake-daemon delivery adapter set with codex-app-server for Codex wake digests.
2. Dispatch via codex debug app-server send-message-v2 <digest> with testable CLI resolution and mockability.
3. Extend the Memory Core MCP schema and any service-side metadata validation needed so harnessTargetMetadata.adapter: 'codex-app-server' is accepted for bridge-daemon routes.
4. Add focused unit coverage proving the wake daemon uses the app-server command for Codex subscriptions and does not fall through to osascript.
5. Add an operator-gated live validation note or post-merge checklist item for a real Codex Desktop delivery, because sandbox tests can prove command shape but not full app-server turn conversion.

Contract Ledger Matrix

Decision Record impact

Aligned-with ADR 0002. This implements the already-documented Codex native-control-plane routing direction for the normal wake-daemon path. It does not amend or supersede ADR 0002.

Acceptance Criteria

• Wake daemon supports harnessTargetMetadata.adapter: 'codex-app-server' and dispatches Codex wake digests through codex debug app-server send-message-v2.
• The Memory Core MCP schema accepts codex-app-server as an adapter value.
• The implementation fails closed on app-server dispatch errors and does not silently fall back to osascript for explicitly app-server-configured Codex routes.
• Focused unit coverage proves command shape, digest payload propagation, and no-osascript fallback for app-server routes.
• Existing osascript, tmux, webhook, and test-adapter wake behavior remains covered or unchanged.
• PR body includes an operator-gated live validation plan for the real Codex Desktop app-server route.

Out of Scope

• Reopening the full post-v13 cycle-state / liveness-ledger work from #12612 or #12633.
• Implementing claimable-now backlog computation, PR-ceiling backpressure, or wake noise-classifier enforcement.
• Re-enabling the disabled wake safety gate; that is operator-controlled until the fresh-session loop hazard is separately cleared.
• Assuming Codex app-server live routing is fully proven by unit tests alone.
• Merging or closing older archived Codex wake tickets.

Avoided Traps

• More prose discipline: rejected. The live incident is evidence that prose-only wake instructions do not reliably create autonomous lane pickup.
• Silent app-server-to-osascript fallback: rejected. A configured native route that quietly falls back to GUI paste recreates the failure mode and hides the evidence.
• Scope creep into the deferred liveness ledger: rejected. This ticket fixes the Codex delivery adapter gap first; broader external enforcement remains a separate substrate.

Related

Parent candidate: #13012

Wake-substrate family: #11829

Historical Codex app-server direction: #10517, #10664, #10679

Deferred liveness/cycle-state work: #12612, #12633, #10777

Origin Session ID: d2d31447-5009-47a8-992e-9ecc35b806c1

Retrieval Hint: Codex app-server wake adapter bridge-daemon send-message-v2 ignored wake prompts