›_ Codex Issues
Codex Issues / #40400

Windows desktop: Work Mode repeatedly restarts app-server during tool calls, leaves missing tool outputs, and consumes usage

Open 💬 4 comments Opened Aug 24, 2026 by ryanmevans34-beep
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

The ChatGPT/Codex Windows desktop app is consistently failing during Work Mode tasks. The visible symptom is the “ChatGPT stopped unexpectedly” recovery screen. Local diagnostics show that the main ChatGPT desktop process remains alive while the Work/Codex app-server child process and renderer are replaced.

After the replacement, affected task histories contain tool calls with no matching result. Resuming those tasks repeatedly logs errors such as:

Custom tool call output is missing for call id: call_iweW5TiGI9ahiCT0LOxFMsWx
Custom tool call output is missing for call id: call_7kDQ4O8ViqbQ7Rfaab8mVLUy

This has happened across multiple Work tasks, not only one conversation.

Impact and usage/credit request

The crashes occur after model/tool work has already started, so failed attempts and repeated restarts consume usage/credits without completing the task. The issue is currently making Work Mode unreliable for me.

Please review whether usage consumed by these crashed runs can be restored/reset. If GitHub maintainers cannot handle account adjustments, please direct me to the correct OpenAI support channel and let me know which session/task IDs are needed.

Environment

  • OS: Windows 10 Pro 64-bit, version 10.0.19045
  • Desktop package: OpenAI.Codex_26.818.5229.0_x64
  • Bundled/local Codex CLI: codex-cli 0.149.0-alpha.4.1
  • Desktop/Chromium file version observed: 151.0.7922.170
  • Failure period in attached logs: August 21–23, 2026, America/New_York

Steps to reproduce

  1. Open the ChatGPT Windows desktop app.
  2. Start or resume a Work Mode task that uses normal tools such as shell commands or web access.
  3. Allow the task to run through one or more tool calls.
  4. The Work session stops and the desktop app shows “ChatGPT stopped unexpectedly.”
  5. Restart or resume the task.
  6. The Work child runtime is recreated, the saved task reports missing custom-tool outputs, and additional usage is consumed while retrying.

Frequency: consistently reproducible across multiple Work tasks during the affected period.

Expected behavior

Work Mode should either complete the tool call or return a recoverable tool error. A child-runtime restart should not leave the task history in a permanently incomplete state, and retries caused by an app crash should not consume additional user usage.

Actual behavior

  • The main desktop process stays alive, but the Work/Codex child process and renderer are replaced.
  • The saved task contains custom-tool calls without matching outputs.
  • Resuming the task repeatedly emits Custom tool call output is missing for call id ....
  • One affected task produced the error across three separate child-runtime process instances.
  • A second and additional older task histories show the same incomplete-call pattern.
  • There was no matching Windows Application Error, WER report, or current Crashpad dump for the child-runtime replacement.

Log summary

From the local Codex log database, filtered to ERROR, target codex_core::util, and the exact missing-output message:

  • 122 matching log entries
  • 10 distinct missing call IDs
  • 5 affected task/thread IDs
  • 12 child-runtime process instances
  • First occurrence: 2026-08-21T12:52:33-04:00
  • Last occurrence: 2026-08-23T16:54:20-04:00

A sanitized excerpt is attached as codex-work-mode-crash-sanitized-log.txt. I have not attached raw session transcripts because they can contain task content and local paths.

Troubleshooting already completed

  • Updated/restarted the desktop app and rebooted Windows.
  • Backed up and validated config.toml before making any changes.
  • Removed stale nonexistent beta plugin entries.
  • Removed an obsolete features.remote_connections setting that the runtime reported as unknown.
  • Set notify = [] after a legacy notification hook repeatedly failed with Windows OS error 206.
  • Verified that the Codex SQLite state databases and global JSON state were structurally valid.
  • Verified that clean, ephemeral strict-config CLI task starts can succeed.
  • Did not delete caches/state or fabricate missing tool outputs.

The crash still recurred in real Work Mode after the safe config cleanup. By August 24, the desktop app had also repopulated the legacy notify hook in config.toml; the same OS error 206 subsequently returned. This may be a separate config-persistence symptom rather than the primary crash cause.

Relevant task IDs

  • 01a02a58-6f27-78d1-8097-49c3638423e6
  • 01a029a0-e45c-7362-bef4-fa90a673c031
  • 01a02a69-dc1b-7ce3-b9ba-ca4527a585eb

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #39029
  • #40231

Powered by Codex Action

maneco2 · 3 days ago

Horrivel esta atualizacao, usei 10% de meus tokens em apenas um unico trabalho, esta demorando 30 minutos para fazer um simples trabalho no Sol 5.6 Medio, ontem eue stava fazendo a mesma coisa no Sol 5.6 Leve em 5 minutos! Oque esta havendo?

marceloadryao · 3 days ago

I reproduced this on the Windows desktop package OpenAI.Codex_26.818.5229.0_x64 / desktop client 26.818.41509 (Chromium file version 151.0.7922.170) and obtained a more deterministic recovery result.

Isolated reproduction

  1. Resume one affected local thread. The thread UI itself opens.
  2. Submit any new message.
  3. During run_turn.prepare_sampling_request_input, the logs emit:

``
Custom tool call output is missing for call id: <redacted>
``

  1. The app-server subsequently exits (observed code 3221225786) and Windows records MoAppHang; the desktop shows “ChatGPT stopped unexpectedly.”

No PostToolUse hook executed in the incident window, so this was not a hook/safeguard rejection.

History inspection

The affected rollout was a very large legacy JSONL history (about 455 MB). A full call/output scan found three persisted custom calls without matching outputs. Only two were in the active recent context; both came from interrupted tool executions.

Migrating the rollout from legacy to paginated history made the thread open more reliably, but did not fix the crash on the next submitted message. This separates the large-history performance factor from the immediate fatal condition.

Minimal repair and A/B result

After making byte-for-byte and SQLite backups, I appended one explicit custom_tool_call_output record for each of the two interrupted active calls. Each synthetic result truthfully states that execution was interrupted, the result is unknown, and the operation must be re-run before relying on it. I did not invent a successful tool result.

After repair:

  • the same thread accepted turn/start;
  • it continued normal model/tool activity for more than three minutes;
  • there were zero new “Custom tool call output is missing” entries;
  • zero prepare_sampling_request_input failures;
  • zero app-server exit signatures;
  • zero new MoAppHang events;
  • the desktop and app-server processes remained alive.

Product-level conclusion

A missing persisted tool output can be caused by a prior interruption, but resuming that history should not terminate the app-server or hang the desktop. The input normalizer should convert an unmatched interrupted call into an explicit recoverable error/interruption result (or reject only the turn gracefully), preserving the invariant that every tool call has an output before sampling.

Raw rollout/log files contain private project data and are not attached. Sanitized excerpts or hashes can be provided privately if useful.

limi124 · 3 days ago

I independently reproduced the same failure pattern on Windows.

Environment at the time of the incident:

  • Windows x64 (10.0.26200.0)
  • Desktop package: OpenAI.Codex_26.818.5229.0_x64
  • Bundled app-server: 0.149.0-alpha.4.1
  • Custom Responses API provider
  • Local thread using ordinary coding tools

The desktop log repeatedly showed this sequence:

Custom tool call output is missing for call id: <redacted>
app_server_connection.closed code=3221225786
Codex CLI process exited classifiedAsExpected=false code=3221225786
fatal_error_broadcasted

This occurred multiple times for the same persisted thread. Restarting the desktop app recreated the app-server successfully, but resuming the affected thread caused the missing-output error and child-process exit again.

As a recovery test, I fully exited the app and moved only the affected rollout JSONL out of the active sessions directory, preserving it as a backup. New threads then worked without repeatedly restoring that affected history. I did not delete SQLite state or fabricate tool outputs.

This appears consistent with an incomplete persisted tool-call pair becoming fatal during history preparation/resume. Even if the missing output originated from an interrupted tool execution or provider disconnect, app-server should reject or normalize that thread gracefully instead of terminating the shared child process.

I can provide additional sanitized timestamps and error signatures if useful, but the raw rollout and logs contain private project content and credentials.