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

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

No source file or test is named. Start with the attached codex-work-mode-crash-sanitized-log.txt and reproduce the Windows Work Mode child-runtime replacement using the listed task IDs, then trace the missing custom-tool outputs across the affected process instances. Done means tool calls have matching results or recoverable errors after a restart, without repeated failed retries consuming additional usage.