Codex app started crashing during agent reasoning/chain of thought 4 times in a row with the restart, update codex, view config.toml as option in the popup that accompanies the crash. restarting doesn’t fix. it happens as soon as the agent runs a command.
djahn
August 13, 2026, 8:44pm
2
I am having the same issue. I was able to use Codex fine yesterday, but this afternoon it started crashing and causing extreme lag when running on my computer. Even with no active sessions, it is making my computer unusable.
EricGT
August 13, 2026, 8:59pm
3
@stevensweden4 @djahn
Welcome to the forum!
You are welcome to discuss Codex issues here. However, the official place to report and track them is the OpenAI Codex GitHub issue tracker .
I asked ChatGPT to look for the closest related issue, and it identified:
opened 08:53AM - 23 Jul 26 UTC
bug
windows-os
tool-calls
app
performance
### What version of the Codex App are you using?
`OpenAI.Codex 26.715.10079.0` … from the Microsoft Store.
Additional version details observed locally:
- Desktop executable: `ChatGPT.exe 150.0.7871.124`
- Bundled Codex runtime: `0.145.0-alpha.30`
- App-server startup logs report client version `26.715.72359`
Windows deployment history shows that `26.715.8383.0` was installed on July 21 and was replaced by `26.715.10079.0` on July 22. The user reports that the older build was stable and that the repeated freezes/crashes began after this update.
### What subscription do you have?
Not provided.
### What platform is your computer?
- Windows x64, OS build `26200.8875`
- Intel Core Ultra 5 225H, 14 logical processors
- 32 GB RAM
- Intel Arc 130T GPU
- Native Windows workspace (not WSL)
### What issue are you seeing?
## Summary
After the Desktop app updated to `26.715.10079.0`, starting or resuming a project conversation and allowing Codex to run ordinary read-only project inspection commands can make the Desktop UI unresponsive while total CPU jumps to approximately 92–100%.
This is not limited to opening multiple windows. A simple text-only conversation may initially remain responsive, while a second/new project conversation freezes around its first shell/tool call. The same failure can later occur in the original single window, especially after project or diagnostic commands produce more output.
After restarting the app, the affected turn is normally marked `interrupted`: the assistant's commentary remains visible, but the shell result was never persisted.
Windows Error Reporting confirms actual application failures, not only perceived UI lag:
- `2026-07-23 13:40:58` — `ChatGPT.exe 150.0.7871.124`, faulting module `KERNELBASE.dll`, exception `0xe0000008`, offset `0x00000000000c1ada`
- `2026-07-23 15:27:54` — the same executable, module, exception, and offset
- During the preceding night, Windows also recorded seven `codex.exe` Application Error events, six sharing exception `0xc0000409` at offset `0x000000000d2cbf31`
- One `codex-code-mode-host.exe` failure was recorded with exception `0x80000003`
## Sanitized local diagnostics
The local SQLite feedback log is not continuously writing while idle, but it shows a large active-use burst:
- 8-second idle sample: `0` new rows and `0 KB` database/WAL growth
- 10-minute active sample: `2,205` rows, including `1,925 TRACE` rows
- Estimated retained log content during that sample: approximately `2.94 MB`
- Peak insertion rate: `206 rows/second`
- `939` TRACE rows contained `unhandled responses event`
- Largest targets by row count:
- `codex_api::sse::responses`: `1,185`
- `codex_app_server::outgoing_message`: `636`
- `codex_core::stream_events_utils`: `79`
- Current files at the time of inspection:
- `logs_2.sqlite`: approximately `13.04 MB`
- `logs_2.sqlite-wal`: approximately `4.21 MB`
This is a correlation, not proof that SQLite logging is the sole cause. It may amplify a renderer/app-server or tool-call failure during active turns.
There were also `1,146` WMI Activity Event ID 5858 failures in a six-hour diagnostic window. Most came from repeated network-adapter statistics queries by historical client PIDs that had already exited, so attribution to Codex is not proven. This may be adjacent to #34014, but the primary evidence in this report is the reproducible project/tool-call trigger and the matching Windows crash signatures.
Plugin churn does not currently appear to be the dominant trigger. After setting `plugins=false` and `remote_plugin=false`, only 13 `plugin/list` matches appeared in the same recent 10-minute window, but the freezes continued.
### What steps can reproduce the bug?
The failure is intermittent but has occurred repeatedly with this sequence:
1. Launch Codex Desktop on Windows.
2. Open a local Git project or create a new conversation associated with that project.
3. Ask Codex to perform a read-only inspection, for example:
- read a small set of handoff/documentation files;
- run `git status` or inspect a short Git log;
- summarize the project without modifying it.
4. The assistant posts its initial commentary and begins a shell/tool call.
5. The Desktop UI becomes unresponsive and total CPU rises to approximately 92–100%.
6. Force-close or restart Codex.
7. Reopen the conversation. The turn is shown as interrupted and no tool result was saved.
A tightly constrained background inspection sometimes completes, which suggests the regression may be burst/size/timing-sensitive rather than affecting every tool call.
### What is the expected behavior?
Ordinary project inspection and shell tool calls should complete without pegging the CPU, freezing the renderer, or crashing `ChatGPT.exe`/`codex.exe`. A new project conversation should remain usable on a 14-logical-CPU, 32 GB machine.
### Troubleshooting already attempted
- Clean uninstall and reinstall from the Microsoft Store
- Moved `CODEX_HOME` from the system drive to a drive with more free space
- Disabled GPU acceleration; the issue persisted
- Disabled plugins and remote plugins; the issue persisted
- Used only one Codex window; the issue still occurred
- Restarted Windows and Codex repeatedly
- Attempted to force HTTP/SSE for a proxy environment; Desktop startup still selected the built-in OpenAI transport/WebSocket capability
The problem began before the transport/config experiments.
### Privacy / attachments
Raw `logs_2.sqlite`, session JSONL, and application logs are intentionally not attached because they can contain prompts, local paths, tool output, and private project content. Sanitized aggregate diagnostics can be provided if maintainers request them.
CPU screenshots are available, showing approximately 92% and 100% total CPU during two freezes, but they contain no useful per-process breakdown and are therefore not attached here.
### Possibly related issues
- #34014 — Windows standalone app / WMI Provider Host at 90–100% CPU
- #34577 — Windows high-CPU PowerShell processes after shell tool calls
- #21134 — Desktop app-server/renderer slowdown with TRACE log churn
- #24275 and #31111 — high-volume `logs_2.sqlite` / TRACE logging during active use
which might be the cause; personally I find the issue a nice jumping off point to look for others.
If that issue matches your problem, consider adding a
If it does not describe the same problem, search the existing Codex issues for a closer match. If you cannot find one, open a new issue and include as much relevant detail as possible.
it’s not my cpu is completely fine, i have no ui freeze, and no kernelbase crashes
UPDATE: The cause is a Codex-on-Windows command-console bug—not your Python code and not a corrupted task.
codex.exe repeatedly exits with 3221225786, which is Windows 0xC000013A (STATUS_CONTROL_C_EXIT). In other words, the Codex app-server receives a Ctrl+C console-control event while pytest is running.
EricGT
August 13, 2026, 9:19pm
6
Ouch!
I did a manual quick search of the Codex issues using is:issue state:open 3221225786 windows and quickly found
opened 07:12PM - 14 Jul 26 UTC
bug
windows-os
extension
app
session
### What version of the Codex App are you using (From “About Codex” dialog)?
26… .707.71524
### What subscription do you have?
ChatGPT Plus
### What platform is your computer?
Windows 11, 64-bit (x64)
### What issue are you seeing?
Codex repeatedly crashes on Windows in both the desktop app and the VS Code integration. The crash occurs a few seconds after submitting a command, including in newly created conversations.
The application repeatedly shows error code 3221225786, signal=null.
Recent error messages include:
- Model personality requested but model_messages is missing, falling back to base instructions.
- Failed to read canonical session metadata.
- Rollout JSONL is empty.
- State DB update_thread_metadata failed.
The issue persists after restarting, resetting, and reinstalling the application, creating new conversations, changing the personality setting, and lowering the reasoning effort. It occurs with different commands and is not limited to one project.
Codex is currently unusable because almost every submitted task causes the application to crash.
### What steps can reproduce the bug?
1. Open the Codex desktop app on Windows 11.
2. Open any existing project or create a new conversation.
3. Enter any command and submit it.
4. Wait a few seconds.
5. The application crashes and displays error code 3221225786.
The problem also occurs in the VS Code Codex integration. It persists after restarting, resetting, and reinstalling the app, creating new conversations, changing the personality setting, and lowering the reasoning effort.
### What is the expected behavior?
Codex should process the submitted command normally without crashing. The conversation and session metadata should be saved correctly, and the application should remain usable.
### Additional information
The crash has occurred repeatedly with different internal warning messages, including:
- Model personality requested but model_messages is missing
- failed to read canonical session metadata
- rollout JSONL is empty
- state DB update_thread_metadata failed
App version: 26.707.71524
Model: GPT-5.6 Sol
Windows 11, 64-bit
Subscription: ChatGPT Plus
The same problem occurs in both the Codex desktop app and the VS Code integration. Screenshots of the errors are attached.
Please let me know which diagnostic logs or session files I should provide for further investigation.
<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/9a3aab49-2e9f-4c16-9751-a47f2fbb2362" />
<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/e6211d43-d8d0-4025-81a9-7d566321274c" />
<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/a34f3556-ae9b-4ad6-b502-afab5463abcd" />
<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/a6d355d6-0f20-4c59-a565-8f9ed2d06c4c" />
Same advice as before, enter a new issue if you think your issue is new or different and upvote the issues using
Also consider
using the Codex /feedback command in a Codex prompt
starting codex with the doctor option when starting Codex from the command line
this can’t possibly be the fix: I’ve applied the fix in [config.toml (line 14)](/C:/Users/omar_/.codex/config.toml:14):
[features]
unified_exec = false
Your config had explicitly enabled the PTY-backed execution backend. Official OpenAI documentation says unified_exec is disabled by default on Windows—which strongly confirms that overriding it was the problem.
reaction on the GitHub issue itself—not only on this forum topic. Reactions on GitHub can help the developers gauge the number of affected users.