[Windows][26.908.4834.0] app-server is replaced immediately after approving elevated command; turn lost / conversation may go blank until restart

What version of the Codex App are you using (From “About Codex” dialog)?

• Windows package: OpenAI.Codex 26.908.4834.0
• Desktop client version reported to app-server: 26.908.40834
• Bundled Codex app-server/CLI: 0.154.0-alpha.6.2

Platform

• Windows 10 Pro x64
• Version/build: 10.0.19045 / 19045

Summary

Codex Desktop intermittently loses an active turn because the local codex.exe app-server process is replaced while work is in progress. The top-level Desktop process remains alive.

Two incidents have now been captured at a precise approval boundary:

1. Automatic approval / Guardian: Guardian returned outcome: allow, but the parent tool call did not resume and the approved command did not launch before the app-server was replaced.
2. Manual user approval: after switching away from automatic approval specifically to test this, the same app-server replacement reproduced immediately after the user manually approved an elevated command.

The manual reproduction materially changes the diagnosis: this is not limited to Guardian/automatic approval. The common failure boundary is now the handoff from an accepted approval to elevated command execution / parent tool-call continuation.

The same installation has shown two related user-visible recovery failures:

• Mode A — partial recovery: the UI flashes/reloads, the active turn stops, the conversation remains visible, and the turn becomes a ▶ retry/play control.
• Mode B — blank conversation: the entire selected conversation content disappears and the composer looks like a brand-new/idle input state. Navigating to other conversations and back does not restore it. Only restarting Codex Desktop makes the conversation history reappear, now in an interrupted/stopped state.

These failures had already occurred repeatedly in existing conversations, including context-heavy ones. A fresh conversation was created specifically to test whether accumulated context/state was the cause; the same failure reproduced almost immediately there as well. This therefore does not appear limited to one stale thread or long-context conversation.

Captured incident A — automatic approval

KST (UTC+9), 2026-09-15:

17:42:49.706  Parent requests an elevated local Python unittest command
17:42:49.728  Guardian V2 begins automatic approval review
17:42:49.728  item/autoApprovalReview/started
17:42:54-55  Guardian performs final read-only inspection
17:42:55      old app-server PID 8292 stops producing logs
17:42:59.476  Guardian rollout: outcome=allow
17:42:59.536  Guardian rollout: task_complete
17:43:02.584  replacement app-server PID 8020 starts from initial setup
17:43:05      Desktop requests thread/resume

The parent rollout ended at the pending elevated tool call and had no corresponding tool-call output. The Windows sandbox log had no launch record for the approved unittest command. Thus, for this incident, the approved command itself did not start before the interruption.

Captured incident B — manual approval

The app was then changed to manual approval and work was continued with a fresh instruction rather than pressing ▶.

A first manual approval at 19:08:36 for a state-inspection command succeeded and produced command output, showing that manual approval does not fail on every request.

The next elevated command reproduced the failure:

19:09:04.831  Parent rollout records elevated Python unittest tool call

19:09:11.750592  app-server receives manual approval response:
                  CommandExecutionRequestApprovalResponse
                  decision=AcceptWithExecpolicyAmendment

19:09:11.750737  parent session receives ExecApproval:
                  decision=ApprovedExecpolicyAmendment

19:09:11.936736  final logs_2.sqlite row from old app-server PID 8020

19:09:13.701996  first row from replacement app-server PID 13772
19:09:13.702142  starting app-server remote control websocket task
19:09:13.706652  app-server request: initialize

19:09:14.097     Desktop issues thread/read
19:09:15.284     Desktop issues thread/resume
19:09:16.477     resumed thread begins responses websocket connection

There is no recorded command output or terminal outcome for the approved unittest before PID 8020 disappears. The parent rollout ends with the custom tool call plus token-usage record and contains no tool-call output after it. The capture does not establish an OS-level exit code or prove whether a child process began during the very small post-approval gap; it does establish that the parent execution never recorded completion and the app-server was replaced immediately afterward.

Process evidence from the manual incident

At diagnostic capture time:

Top-level ChatGPT.exe PID 12900
created: 16:14:08
still alive

replacement codex.exe app-server PID 13772
parent: ChatGPT.exe PID 12900
created: 19:09:13

New renderer processes were also created at 19:09:13-14, while the original top-level Desktop process remained alive. This matches the visible flash/reload and subsequent UI rehydration behavior.

logs_2.sqlite process UUID boundary:

old app-server PID 8020:
  captured logs through 19:09:11.936736

replacement app-server PID 13772:
  first captured log 19:09:13.701996

Blank-conversation recovery failure

In the manual-approval incident, recovery was worse than the earlier ▶ state:

active conversation / task
        ↓
manual approval accepted
        ↓
app-server replaced + renderer generation recreated
        ↓
selected conversation body becomes completely blank
        ↓
composer looks like an initial idle/new-input state
        ↓
switching to another conversation and back does not restore content
        ↓
full Codex Desktop restart is required
        ↓
conversation history reappears in interrupted/stopped state

A screenshot of the blank state was captured. It shows the conversation title still selected while the entire body is empty and the composer is in its normal idle input state. It can be provided if maintainers need it.

This suggests that persisted conversation data survives, but the running Desktop instance can fail to rehydrate/rebind the selected thread after app-server replacement.

Diagnostics already checked

• Codex Desktop reports no newer update.
• Failure reproduces across existing conversations and a fresh conversation.
• Both automatic approval and manual approval have now reproduced the same app-server replacement class.
• No VPN, proxy, secure-DNS tunnel, or corporate network involved.
• No normal GPU/render corruption such as black-hover corruption, ghosting, or menu flicker.
• Windows Application log: no matching Application Error, Application Hang, or Windows Error Reporting event in either captured incident window.
• Crashpad reports directory: no incident .dmp / report found for the first captured incident.
• Top-level Desktop process survives while the local app-server is replaced.

What is established vs. not established

Established by local evidence:

• approval is accepted;
• the parent tool call does not produce its normal result;
• the current app-server stops logging almost immediately afterward;
• a different app-server process initializes from scratch;
• Desktop subsequently issues thread/read / thread/resume;
• the UI can recover either as ▶ retry or as a blank conversation requiring full Desktop restart.

Not established:

• exact Windows termination/exception code for these incidents;
• whether the Desktop supervisor intentionally terminates the app-server or it crashes independently;
• that Guardian causes the failure (manual approval disproves Guardian as a required trigger);
• that #45020's 0xC000013A is the local exit code here.

No panic or explicit process exited line was captured from the dying app-server in these failure windows.

Expected behavior

• Once an approval is accepted, the parent tool call should continue reliably into the approved execution.
• A failure during approved-command dispatch should fail that tool call explicitly rather than silently losing the app-server.
• If app-server restart is unavoidable, active-turn state and per-tool execution state should survive so Desktop can safely resume or clearly report what did/did not execute.
• Thread rehydration after app-server replacement should not leave a selected conversation permanently blank until the whole Desktop application is restarted.
• The app should preserve a useful termination/recovery reason when an app-server instance is unexpectedly replaced.

Related issues

• #45075 — very close user-visible symptom: Desktop reload during active task and interrupted turn becomes ▶. It was self-closed by its reporter with no public maintainer-confirmed fix or linked fix PR.
• #45219 — same package/build family; tool execution / app-server recovery leads to missing tool state and blank conversation content; reproduces in a fresh conversation.
• #45020 — Windows 10 build 19045 + 26.908.4834.0 + same app-server generation; another environment confirms repeated child app-server exits. This report does not claim its 0xC000013A exit code locally.
• #32538 — Windows automatic-approval lifecycle failures. Relevant to approval handoff, but the current manual reproduction shows the present issue is broader than auto-review.
• #43852 — Windows Desktop can lose an active terminal/session while the app remains/restarts its local execution state.
• #44315 — app-server crash/restart can present as UI flash/reload on Windows, though that report has a different confirmed exception signature (0xC0000005) and WER evidence not present here.

Request

Please investigate the Desktop/app-server lifecycle specifically around:

approval accepted
  → ExecApproval / policy amendment applied
  → approved command dispatch
  → parent tool-call continuation

The second capture narrows the failure to this common post-approval path rather than Guardian itself. Please also investigate why Desktop can issue thread/read / thread/resume after replacement yet still leave the selected conversation body blank until a full application restart.

Privacy-sensitive raw rollouts, project content, full logs, and account identifiers are intentionally not attached. Narrow sanitized excerpts and the blank-state screenshot are available on request.

Start by tracing the Desktop/app-server lifecycle from approval acceptance through ExecApproval, approved command dispatch, and parent tool-call continuation. Then inspect the thread/read and thread/resume recovery path after app-server replacement. Done means identifying the replacement trigger, preserving or explicitly failing the tool call, and preventing the selected conversation from remaining blank.