Best possible solution:

Land a narrow Codex app-server notification-yield fix after maintainer review and live or diagnostic proof that account and MCP status notifications no longer stall gateway liveness.

Do we have a high-confidence way to reproduce the issue?

No high-confidence live reproduction was run in this review. The linked issue gives concrete production liveness logs and current source confirms the queued notification projection path, so this is source-reproducible rather than fully reproduced here.

Is this the best way to solve the issue?

Yes, this is a narrow maintainable direction for the reported queue starvation: keep pre-turn capture synchronous and yield before projector work. The missing piece is real runtime proof that the liveness symptom improves under the reported Codex/MCP or cron path.

Acceptance criteria:

• node scripts/run-vitest.mjs extensions/codex/src/app-server/run-attempt.test.ts -t "yields a macrotask|preserves Codex usage-limit reset details"
• node scripts/run-oxlint.mjs extensions/codex/src/app-server/run-attempt.ts extensions/codex/src/app-server/run-attempt.test.ts
• Live or diagnostic Codex app-server proof for account/rateLimits/updated and/or mcpServer/startupStatus/updated without gateway liveness regression

What I checked:

• PR diff: The patch adds waitForCodexNotificationDispatchTurn() using setImmediate, awaits it before projector.handleNotification(notification), and short-circuits pre-turn notifications into pendingNotifications before the queued projector path. (extensions/codex/src/app-server/run-attempt.ts:1319, 9437eb990235)
• Current main notification queue: Current main registers enqueueNotification, chains notifications through notificationQueue.then(...), and awaits projector.handleNotification(notification) inside that queued handler. (extensions/codex/src/app-server/run-attempt.ts:1239, 0ad3d25fb7cd)
• Client dispatch contract: The app-server client invokes notification handlers via Promise.resolve(handler(notification)) without awaiting them, so the per-run queue is the local serialization point for projection work. (extensions/codex/src/app-server/client.ts:467, 0ad3d25fb7cd)
• Rate-limit projection path: The projector currently special-cases account/rateLimits/updated by storing the payload in latestRateLimits and the shared rate-limit cache before returning. (extensions/codex/src/app-server/event-projector.ts:172, 0ad3d25fb7cd)
• Regression coverage in PR: The diff adds a focused test asserting a rate-limit notification is not projected after one microtask but is projected after the queued processing promise resolves, plus a turn/start failure rate-limit preservation adjustment. (extensions/codex/src/app-server/run-attempt.test.ts:1986, 9437eb990235)
• Real behavior proof gate: The PR body reports targeted harness tests and oxlint only, and explicitly says live Codex OAuth/MCP gateway runs, Telegram delivery, AWS health checks, and production cron-triggered embedded runs were not tested. (9437eb990235)

Likely related people:

• steipete: The app-server protocol bridge commit touched client.ts, run-attempt.ts, protocol, tests, and Codex command surfaces; recent run-attempt history also shows multiple app-server timeout and harness fixes. (role: original app-server bridge and recent area contributor; confidence: high; commits: 69566e43cb8b, 934fc6ceeb10, 1e31bd2ac29d; files: extensions/codex/src/app-server/client.ts, extensions/codex/src/app-server/run-attempt.ts)
• pashpashpash: The usage-limit reset details commit added rate-limit-cache.ts and touched event-projector.ts, run-attempt.ts, and their tests; recent event-projector work also touched projection behavior. (role: rate-limit and event-projector contributor; confidence: medium; commits: b2c3202a15e7, 1a5548203e09, 78eb92e62277; files: extensions/codex/src/app-server/event-projector.ts, extensions/codex/src/app-server/rate-limit-cache.ts, extensions/codex/src/app-server/run-attempt.ts)
• jalehman: Recent history shows work on app-server surrogate stalls in client.ts and MCP server preservation in the app-server harness, both adjacent to this notification-liveness report. (role: recent Codex app-server client and MCP-adjacent contributor; confidence: medium; commits: f64feab47a66, 1ee0d51e92f6; files: extensions/codex/src/app-server/client.ts, extensions/codex/src/app-server/run-attempt.ts)
• zknicker: A same-day merged change touched both central files and their tests for Codex app-server prompt mirror behavior, making this a useful routing signal for current-main context. (role: recent run-attempt/event-projector contributor; confidence: medium; commits: 7715b29aa231; files: extensions/codex/src/app-server/event-projector.ts, extensions/codex/src/app-server/run-attempt.ts, extensions/codex/src/app-server/run-attempt.test.ts)

Remaining risk / open question:

• The PR body does not include after-fix proof from a live Codex OAuth/MCP gateway, production-like cron run, or AWS/liveness environment.
• The focused regression test proves queue yielding for a synthetic rate-limit notification, but does not exercise a real mcpServer/startupStatus/updated payload or gateway health checks.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 0ad3d25fb7cd.