[Bug]: Codex turn retries stay closed after App Server SIGKILL

[matheustimbo]

Bug

After the Codex App Server is terminated by SIGKILL, sending another message to the same T3 thread repeatedly fails with ProviderAdapterSessionClosedError: codex adapter thread is closed. Retrying the message does not recreate the Codex process. The T3 server itself remains healthy.

Observed on Linux with T3 Code v0.1.69. In the incident, the process exited hours before the next user message; both the first message and its retry failed against the same closed adapter thread.

Reproduction

1. Start a Codex-backed T3 thread and let its App Server session become active.
2. Terminate that App Server process with SIGKILL (for example, through a memory pressure manager).
3. Send a new message to the same thread, then retry it.

Expected: T3 marks the old session as exited and resumes the native Codex thread in a fresh App Server process before sending the new turn. The interrupted turn itself need not be replayed.

Actual: The adapter keeps routing turns to the closed process; each send fails with ProviderAdapterSessionClosedError.

Diagnosis and related work

Two lifecycle gaps combine in this case:

• Signal termination makes child.exitCode fail, while the runtime watcher only handles a successful numeric exit status. Consequently it can miss session/exited for SIGKILL.
• Even when an exit event is emitted, the Codex adapter can retain the dead runtime in its session map, so hasSession remains true and recovery is skipped.

Related: #10798 describes the retained session and indefinitely running UI state. #10799 addresses adapter cleanup; #10874 addresses signal exits. This issue tracks the user-visible repeated-turn failure when both gaps occur together and the need for an integration regression covering the full path.

[andydoucet]

Confirmed the same failure after SIGSEGV, not only SIGKILL, on Linux x86_64 today (2026-09-29).

Environment: T3 Code Nightly desktop on Arch Linux, Codex CLI 0.158.0. The installed distro package reports t3code-nightly-bin 0.0.43_nightly.20260929.2416-1 (the desktop process was already running before today's package update, so this is the installed package version rather than a verified in-memory build version).

Observed sequence:

1. The Codex App Server subprocess crashed at 16:12 MDT. coredumpctl confirms signal 11 / SIGSEGV in a Tokio worker thread.
2. T3 itself stayed running, but every subsequent message to the affected conversation failed with ProviderAdapterSessionClosedError against the same closed adapter.
3. The server trace's nested cause was:

   CodexAppServerTransportError: read-process-exit-status
     PlatformError: Unknown: ChildProcess.exitCode
       Error: Process interrupted due to receipt of signal: 'SIGSEGV'
   

4. Sending thread.session.stop through T3's authenticated orchestration API cleared the dead session. A harmless verification turn in the same conversation then completed successfully; session status returned to ready, lastError became null, and the saved conversation remained intact. No desktop/server restart or custom application build was required.

Additional verification: a local real-process runtime test using SIGTERM reproduced the missing session/exited event in the unpatched runtime. Handling the failure branch of child.exitCode made that test pass, alongside numeric exit-code 0 and 1 cases. This supports the signal-exit part of the diagnosis; it is not a claim to have fixed or explained the underlying Codex SIGSEGV.

As of upstream main ff1db030b179ef712cacc0098366d976e2877f45, CodexSessionRuntime.ts still observes child.exitCode using success-only Effect.flatMap. #12922 appears to cover this failure plus the adapter cleanup/race cases; it is still unmerged. Adding this incident as another real-world confirmation and a request to prioritize that recovery fix.

No core dump, conversation content, credentials, or private project details are attached.