[Beaten0123]

Problem (reproduced against real WebCodex SQLite)

An Oct 31 attention_event Wake remains delivery_unknown and blocks every later pending Wake for the same Agent in claim_next_agent_wake. A Nov 15 agent_task_attempt Wake expired and retired without being claimed. MCP App Endpoint binding/readiness was true but Host model turn never exact-consumed the new Wake.

Fix

• Retire only stale attention_event delivery_unknown notifications after a bounded 15-minute grace, atomically revoking their exact Wake Attempts and preserving source attention/audit records.
• Do not retry uncertain ui/message, and never auto-retire prepared/delivered/inbox/AgentWait/execution-bound AgentTask Wakes.
• Prefer valid short-lease agent_task_attempt Wakes over older pending notification Wakes.
• Make exact and implicit read-only bootstrap skip stale uncertain notification so an already-bound MCP App controller can drop its cached old claim and acquire a new Wake.
• Regression proves early block, old Token rejection after retirement, durable pending notifications, and successful claim/prepare/exact-consume of a new AgentTask Wake.

Verification (local, isolated latest-main worktree)

• cargo fmt --all -- --check: pass
• cargo test -p webcodex-store --lib --offline --quiet: 327 passed, 0 failed, 4 ignored
• cargo check -p webcodex --bin webcodex-server: pass
• cargo test -p webcodex --lib agent_continuation_tests --offline --quiet: 25 passed
• cargo test -p webcodex --lib mcp::tests::agent_continuation_app --offline --quiet: 11 passed
• git diff --check: pass
• Local commit: 42908201de343edcb284f4a825b2388ee6bc49cf; fork branch verified same SHA.

Acceptance boundary

This PR proves the server/store and MCP App adapter contracts in-process. It does NOT assert that the deployed ChatGPT Host has scheduled and exact-consumed a fresh Wake. Installed production Server is a separate older build; real Host acceptance requires maintainers' deployment followed by a fresh Wake's exact consume_agent_wake record. Do not mark an unfinished durable Goal completed from this PR alone.

[swjnxyf]

Reviewed PR #1420 at a460d3b9ebaeffadd202737e1ed9e5275c231916 directly in the special primary checkout (no worktree). No blocking source-code issues found; LGTM.

I traced the new recovery path through claim_next_agent_wake, exact and implicit read-only bootstrap_agent_conversation, consume_agent_wake, Task Attempt expiration, endpoint execution bindings, and the existing one-shot Host dispatch fence:

• Only delivery_unknown attention-event Wakes older than the 15-minute grace are retired; their exact wake attempts/tokens are revoked in the same SQLite transaction, with source attention/audit facts preserved. No uncertain ui/message is replayed.
• delivery_unknown Task Wakes are retired only after both the 15-minute window and terminal/expired source Attempt lease conditions. The existing mutually exclusive Task execution backends remain enforced; expiration does not silently revive an outcome-unknown CodingAgent run.
• The read-only bootstrap hides only eligible stale uncertain Wakes, while the canonical authorized acquire performs retirement and selects fresh short-lease Task Wakes ahead of pending notifications. Older pending notifications remain durable.
• A racing late exact consume and an authorized retirement serialize under the Store's immediate transaction. Late revoked tokens cannot consume the retired Wake.

On special: cargo test --locked --offline -p webcodex-store --profile dogfood --lib passed 328 tests (0 failed, 4 ignored); agent_continuation_tests passed 25/25, mcp::tests::agent_continuation_app passed 11/11; cargo fmt --all -- --check and git diff --check passed. The Store regression covers both old-token refusal and a successor Task Wake's exact consumption.

CI caveat (not caused by these four changed files): GitHub run #43710045930 is red in test-linux-tooling and contract because the unchanged scripts/tests/test_build_identity.py suite reports the same four len(outputs) == 1 assertions failing (regular repo and linked worktree). The test aggregator then fails. The same five Build Identity self-tests pass locally on special (5/5), while Linux Server/Runner/Store-related CI jobs have passed. This is a repeatable CI runner/toolchain-dependent discrepancy, not evidence of Wake test regression and not a generic timeout/flaky test; it warrants separate tooling investigation. Please keep required CI checks enforced before merging.

Finally, the tests prove Store and MCP App in-process contracts, not that the deployed ChatGPT Host has scheduled or exact-consumed a new Wake. Production acceptance still requires observing a fresh consume_agent_wake record.

[swjnxyf]

Follow-up on the red CI: I reproduced the four failing Build Identity assertions on special using the exact Cargo 1.100.0 toolchain from GitHub Actions. This is due to Cargo's changed intermediate build-script output layout, not to the Agent Wake changes in this PR.

I fixed the test-only output discovery on our repository in #1421 (commit 6c8c55c0c). It now uses the build-script-executed JSON OUT_DIR and supports both the old output and Cargo 1.100's run/stdout. Both Cargo 1.95.0 and 1.100.0 pass all 5 Build Identity tests; the full Cargo 1.100 release static/tooling suite also passes (904 Python tests, 32 skipped, plus npm/release smoke).

Since this PR's fork has maintainer_can_modify=false, I could not push the unrelated test repair directly here. Please keep this PR's required CI enabled; after #1421 lands in main, we should revalidate #1420 against the updated base. No changes to the Wake implementation are needed for this tooling failure.

[swjnxyf]

Thanks for the additional Wake fixes. #1421 has now been merged into main, including the Cargo 1.100 Build Identity test fix that caused the test-linux-tooling / contract failures on this PR.

Could you please update your PR branch fix/chatgpt-host-wake-resume-20261115 from the latest upstream yyjeqhc/webcodex:main (merge main into your branch, or rebase if you prefer), and push the result? The fork has maintainer_can_modify=false, so I can't update that branch on your behalf.

Once the updated branch is pushed, GitHub Actions should trigger a new CI run automatically; I'll review the fresh results and the additional Wake commits. Please don't merge this PR into main yet, and let's keep the existing required checks enabled until the new run passes.