Windows Codex Desktop: app-server connection fails during tool execution with “Custom tool call output is missing”, conversation pane becomes blank

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

26.908.4834.0

What subscription do you have?

Plus plan

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Observed behaviour

1. Start a Codex development task against a local repository.
2. Codex operates normally and executes tools/commands for some time.
3. During execution, the task/conversation content suddenly disappears.
4. The main Codex Desktop application remains running.
5. The conversation shell remains visible, but the content pane is blank.
6. No conventional Windows Application Error / Windows Error Reporting crash was recorded during the observed failure window.
7. Retrying in a fresh Codex conversation reproduced the problem.

What steps can reproduce the bug?

Reproducibility
Reproduced multiple times on the same day.
Importantly, it reproduced after creating a new Codex conversation, so simply abandoning the affected conversation does not resolve it.

What is the expected behavior?

Expected behaviour
A tool failure, app-server restart/reconnect, or missing tool result should not destroy the visible conversation state.
If an individual tool call cannot be recovered, Codex should fail that turn cleanly and preserve the existing conversation/task history so the user can inspect the error and resume safely.

Additional information

Environment

• OS: Windows 11
• Codex Desktop package: 26.908.4834.0
• Codex/Chromium component observed: 152.0.7977.83
• Date reproduced: 13 September 2026
• Failure reproduced across multiple Codex conversations, including a brand-new conversation
• Workload: local software-development task operating against a Git repository
  Problem
  While Codex Desktop is executing a relatively long, tool-heavy development task, the conversation/task content suddenly disappears from the application.
  The Codex window itself remains open. The surrounding application shell, selected conversation and composer remain visible, but the conversation/task pane becomes completely blank.
  Restarting the application allowed work to be attempted again, but the same failure subsequently occurred again. I then created a completely fresh Codex conversation and retried the task. The failure reproduced there as well.
  This therefore does not appear to be limited to one stale or unusually long conversation.
  Observed behaviour

1. Start a Codex development task against a local repository.
2. Codex operates normally and executes tools/commands for some time.
3. During execution, the task/conversation content suddenly disappears.
4. The main Codex Desktop application remains running.
5. The conversation shell remains visible, but the content pane is blank.
6. No conventional Windows Application Error / Windows Error Reporting crash was recorded during the observed failure window.
7. Retrying in a fresh Codex conversation reproduced the problem.
   Important log evidence
   At approximately 2026-09-13 11:45:48 UTC (12:45:48 BST), the Codex logs record:
   Custom tool call output is missing for call id: call_ZE4y7G7iPBpIQIDd9hSSjHGZ
   The local connection then enters a failed/error state. Shortly afterward the application reconnects.
   The desktop logs subsequently show the renderer/application routes being mounted again, with a long recovery/startup interval.
   The logs also contain repeated conversation-state anomalies during the same session, including:
   Received turn/started for unknown conversation
   followed by successful thread/read activity and then:
   Conversation state not found
   There are also occurrences of:
   Received broadcast but no handler is configured method=thread-read-state-changed
   These events make the failure appear related to Codex Desktop/app-server conversation or tool-call state recovery rather than the underlying repository operation.
   Expected behaviour
   A tool failure, app-server restart/reconnect, or missing tool result should not destroy the visible conversation state.
   If an individual tool call cannot be recovered, Codex should fail that turn cleanly and preserve the existing conversation/task history so the user can inspect the error and resume safely.
   Actual behaviour
   The app remains alive, but the conversation/task pane becomes blank and the active development session is effectively unusable.
   Reproducibility
   Reproduced multiple times on the same day.
   Importantly, it reproduced after creating a new Codex conversation, so simply abandoning the affected conversation does not resolve it.
   Repository integrity
   The underlying Git repository did not itself appear corrupted by the failure. After an earlier occurrence I independently inspected the repository from PowerShell and found a coherent branch/HEAD and recoverable uncommitted changes.
   I have stopped retrying the development task in Codex Desktop to avoid unnecessary risk to in-progress work.
   Potentially relevant observation
   Diagnostic output indicated Codex Desktop package version 26.908.4834.0. Runtime/component information observed during diagnostics may indicate separately versioned Codex runtime components.
   I have not reset the application, cleared its caches/state, reinstalled it, or manually modified Codex's local state, so the affected installation has been preserved for further diagnosis.
   Diagnostics available
   I can provide:

• Codex Desktop logs covering the failure;
• exact failure timestamps;
• process information;
• installed package/version information;
• Windows Application event-log results;
• the full sequence surrounding the Custom tool call output is missing error;
• screenshots showing the blank conversation pane.
  Please let me know which logs/state files would be most useful before I reset or reinstall the application.

Start with the Codex Desktop logs around the “Custom tool call output is missing” event, then trace the app-server connection/reconnect and conversation-state handling mentioned in the report. Compare the unknown-conversation, conversation-state-not-found, and blank-pane sequence across the supplied logs. Done means a failed tool call or reconnect preserves the visible conversation history and leaves the task in a recoverable state.