Repository navigation
Windows Codex Desktop: app-server connection fails during tool execution with “Custom tool call output is missing”, conversation pane becomes blank #45219
Description
Activity
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
thread id 01a0927c-8b61-7f81-a9a2-3d778edbc5e3
Additional reproduction evidence after further isolation:
The issue continues to reproduce consistently in Codex Desktop when switching to Full Access and beginning repository-mutating/tool execution.
Environment:
- Windows 11
- ChatGPT/Codex Desktop version: 26.908.4834.0
- Repository: local Git repository on NTFS
- Model: GPT-5.6 Sol
- Failure has reproduced across multiple fresh Codex conversations
Troubleshooting performed:
- Restarted ChatGPT/Codex Desktop.
- Restarted Windows.
- Windows "Repair" operation completed successfully.
- Uninstalled ChatGPT completely.
- Restarted Windows.
- Reinstalled ChatGPT from Microsoft Store.
- Confirmed freshly installed version remains 26.908.4834.0.
- Upgraded account from Plus to Pro, ruling out the earlier hypothesis that low remaining usage/quota transitions were responsible.
Important A/B result after fresh reinstall:
READ-ONLY / restricted session:
- Started a brand-new Codex conversation.
- Performed a real repository inspection.
- Approximately 10+ repository/tool operations completed successfully.
- Files, Git status/diff, and shared implementation seams were inspected.
- No app-server, conversation-state, or tool-call errors occurred.
- Conversation remained fully functional.
FULL ACCESS session:
- In the SAME conversation, switched to Full Access.
- Submitted a bounded task requiring repository edits and synthetic test execution.
- Codex acknowledged the task and began:
"I'll continue from the six-file dirty candidate and keep all validation on synthetic fixtures. I'll inspect the current test coverage first, close any focused gaps, then run the requested focused and seam checks." - UI showed "Ran commands".
- The Codex conversation then failed/disappeared almost immediately.
This is the same failure pattern seen repeatedly before the reinstall.
The failure therefore now appears correlated specifically with Full Access / mutating tool execution rather than:
- conversation age;
- a particular Codex conversation;
- Windows uptime;
- application installation corruption;
- low remaining weekly usage;
- Plus vs Pro subscription;
- long-running tasks;
- the repository being unreadable.
Read-only Codex Desktop operation is consistently stable. Full Access repository-mutating execution has repeatedly caused the conversation/tool state to disappear.
The issue has also previously produced evidence consistent with missing tool-call/session reconstruction state (including "Custom tool call output is missing" behaviour).
No repository corruption has been observed after these failures. Git state remains recoverable, but the Codex session becomes unusable mid-task.
At this point the most reproducible sequence is:
- Open a fresh Codex Desktop conversation against a local repository.
- Keep normal/restricted access.
- Perform multiple read-only Git/file inspection operations — succeeds.
- Switch the same conversation to Full Access.
- Start a task requiring repository edits/tool execution.
- Codex begins executing commands.
- Conversation/tool output disappears or session becomes unusable shortly afterwards.
Happy to provide additional logs or run a targeted diagnostic if useful.
This happens reproducibly in codex cli on Linux too.
I have accidentally reproduced it under a very certain condition several times in the last 3 weeks-- Start conversation XYZ with permissions set to "Ask for Approval", Let conversation spawn 3 subagent tasks.
- Set a /goal active
- Realize accidental permissions approval not being set to Full Access are terminal for autonomy
- Accidentally hard stop codex and dont continue that conversation
"codex update" a day or two later
- codex resume XYZ
Very oftenThe application panicked (crashed). Message: Custom tool call output is missing for call id: call_hARIepuajvldn3HMGFFwGAM3
Conversation is now dead after that output, nothing fixes it other than manual edits to jsonl.
Above is the reproducible behavior, but in practice, I have lost work through this bug several times due to this exact flow, it is frustrating.I have had this just now in the app. To try and work around I used the cli instead - and (at least in my case) the cli ALSO exited when running a specific task.
TLDR is that the codex app doesn't seem to handle tool calls which exit in an unexpected manner in some cases. (In my case a bad git commit which threw a fatal error).Additional Windows Desktop reproduction, still present September 20, 2026.
Several existing local tasks stop progressing or appear to stop, and opening them shows a completely blank conversation pane while the task title, surrounding UI, and composer remain visible. A completion indicator may also be absent.
The problem persisted across:
- Windows package 26.911.7940.0;
- a verified rollback to package 26.908.9136.0 (displayed app version 26.908.70816);
- a subsequent update to package 26.915.4065.0 (build 9922 in logs).
Fully quitting/restarting did not resolve it. These comparisons do not establish which release introduced the issue.
Read-only task-tool inspection could still retrieve saved history for an affected task despite the blank Desktop pane. Some inspected turns were interrupted with no final answer; another was marked completed with an empty items array. This does not establish that all history is intact or all failures share one cause.
Sanitized local log evidence on September 20:
- 16:00:18 UTC:
Custom tool call output is missing for call id: <redacted>(two call IDs). - Around 16:00:51–16:00:54 UTC: local app-server connection entered an error/reconnecting state, then reconnected; logs included exit code 3221225786.
- Earlier affected sessions also logged
Received turn/started for unknown conversationandReceived turn/completed for unknown conversation.
The missing-output messages preceded the recorded connection failure, but I cannot establish that they caused termination or the blank pane. Affected tasks include collaboration/subagent work; Full Access was enabled, but no controlled permissions A/B test has been performed here.
Is there a supported diagnostic or recovery procedure for existing affected tasks that preserves history? Would a targeted check of missing tool-call/result pairs or the paginated history index help distinguish a transcript issue from Desktop rendering/state recovery? Please advise which minimal sanitized diagnostics would be useful.
No private transcripts, project paths, credentials, or screenshots are included.
Follow-up to my earlier reproduction comment (#45219 (comment)): this update is written and posted by Codex on the account owner's behalf, with their explicit authorization.
We have now identified and repaired a concrete trigger in this user's local workload. A Python process-liveness helper used
os.kill(pid, 0). On Windows,signal.CTRL_C_EVENT == 0, so this is not the harmless Unix-style process-existence check the helper intended.Two persisted task histories recorded launches of probes invoking this helper immediately before the local Codex app-server exited with 3221225786 / 0xC000013A (STATUS_CONTROL_C_EXIT):
- September 20, 19:29:20.217 UTC probe launch → 19:29:22.852 UTC backend exit (2.635 seconds).
- September 20, 19:47:44.827 UTC probe launch, explicitly invoking the helper on its own PID → 19:47:46.537 UTC backend exit (1.710 seconds).
The user confirms they did not manually stop a command or close a terminal. Exact Windows console-event propagation was not instrumented, but the repeated timing and mechanism provide strong evidence for this workload-triggered termination.
After replacing the helper's Windows implementation with a non-signalling process query, the previously failing real-process/lock probes completed successfully around 20:22 UTC and again around 20:25 UTC. They correctly checked live/dead processes and exercised stale-lock recovery, and the task continued afterward. No further backend exits were found in the inspected desktop logs from 20:00 UTC through that review. A Chromium trace covered the first successful run, although its buffer filled; persisted tool results independently confirm probe completion.
Correction/clarification: our earlier report should NOT be treated as evidence that a Codex update caused these particular backend terminations. The local workload defect is repaired, and the existing unit tests had missed it because relevant tests mocked the liveness function.
The persistent blank conversation/history after backend interruption remains an unresolved symptom in this user's report; we have not established whether it shares this cause or constitutes a separate recovery/rendering defect. We also cannot generalize this diagnosis to other reporters' failures. No Codex application or stored conversation data was modified to obtain the successful probe results.
Additional current-build log evidence; no claim that the blank-pane/crash symptom is reproduced
Observed on 2026-10-11 (Asia/Shanghai, UTC+08). Windows 11 Pro, version/build 10.0.26200 / 26200. Desktop updater reported 26.1007.21434, build 13901, prod, up_to_date earlier the same day; MSIX package 26.1007.2314.0; bundled CLI 0.162.0-alpha.17.2. These are separately versioned components.
Existing logs recorded the following on 2026-10-11 (UTC+08), while performing a tool-based desktop diagnosis:
- 12:39:28 through 12:41:38: codex_core::util logged Custom tool call output is missing for call id: .
- 12:43:55 in another active task: codex_app_server_protocol::protocol::thread_history logged dropping turn-scoped item for unknown turn id, for multiple items in one turn.
Repeated log lines are not being counted as independent task failures. Commands could still complete and write/read diagnostic files. This observation does not prove that the desktop crashed, a conversation pane went blank, or files were lost. The relationship between the two log signatures is unconfirmed. A minimal deterministic trigger has not been isolated.
Please help determine whether these current-version history-reconstruction/tool-output anomalies belong to this issue or should be tracked separately, and identify the smallest supported diagnostic needed. We have not edited session databases, fabricated missing outputs, deleted chats or reset the user's history. The requested outcome is reliable preservation and display of actual tool results across turns, with an explicit recoverable error if a result cannot be associated.
Submitted on the account owner's explicit request. This comment contains no account names, personal paths, credentials, cookies, private query parameters, screenshots, raw logs or conversation content.
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
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
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
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:
Please let me know which logs/state files would be most useful before I reset or reinstall the application.