Sending more details will cause the Codex software to freeze

Additional Windows reproduction and diagnostics, migrated from duplicate #32117:

• Reproduced on Windows 11 with Codex App 26.707.3748.0 while the agent runtime was running in WSL.
• Trigger: open the side chat during an active task, add a follow-up, then click Add to task.
• The UI becomes unresponsive, but the backend Goal and subagents continue running and the session rollout continues growing.
• One Chromium renderer remains in a sustained one-core CPU loop while the WSL app-server stays alive.
• After the backend turn completes, the affected thread remains thread-specific: other chats open normally, but reopening that one thread immediately reproduces the UI freeze.
• Desktop logs repeatedly request thread/turns/list for the affected thread with multi-second responses while the renderer is saturated.
• A full restart reproduces the problem when the affected thread is restored. Moving only Chromium Session Storage aside after backup lets the app open on a neutral screen; reopening the affected thread reproduces the freeze again.
• No chat/session data was deleted. A large, tool-heavy rollout may amplify the issue, but it is not confirmed as required.

Original duplicate report and detailed evidence:

• #32117
• https://github.com/openai/codex/issues/32117#issuecomment-4934970125
• https://github.com/openai/codex/issues/32117#issuecomment-4935484929

Confirmed on macOS with Codex App 26.707.31428 (bundle 5059).

Environment:

• macOS 26.5.1 (build 25F80)
• Apple Silicon / arm64
• Main task model: GPT-5.6 Sol, Extra High
• “More details” side conversation: GPT-5.6 Sol, Instant

Reproduction:

1. Open a conversation inside a project.
2. Highlight part of an agent response and select More details.
3. Send one reply in the resulting side conversation.
4. Click Add to task.
5. Confirm that the side-conversation reference appears in the main task’s input box.
6. Press Send.

Actual result: the entire Codex app freezes.

Expected result: the message should be sent with the referenced side conversation attached, and the app should remain responsive.

This began after updating to the current Codex release.

Additional confirmed Windows reproduction with local crash diagnostics.

Environment

• Microsoft Windows 11 Home, version 10.0.26100 (build 26100), x64
• Microsoft Store package: OpenAI.Codex 26.707.9981.0
• ChatGPT.exe version: 150.0.7871.115
• Microsoft Store reported no newer package version when checked on 2026-07-15

Reproduction

1. Start a conversation in Quick Chat / ChatGPT.
2. Select Add to task to bring the conversation into a Codex task.
3. Send the task.

This user reports that the app freezes and crashes every time this flow is used.

Local evidence

At 2026-07-14 22:28 Asia/Shanghai (14:28 UTC):

• Windows Application log recorded Application Hang, Event ID 1002: ChatGPT.exe stopped interacting with Windows and was closed.
• Windows Error Reporting classified it as MoAppHang (Report ID 8210e223-90de-4896-baf1-6f23e70cb16f).
• WER recorded RADAR_PRE_LEAK_64 for ChatGPT.exe about 38 seconds before the hang. This is correlation, not a confirmed root cause.
• The Codex desktop log recorded the local Codex CLI/app-server process exiting with code 1 at 14:28:03 UTC, followed by: Recoverable Chromium child process gone ... processType=GPU reason=killed.
• Windows generated WER minidump/memory-dump artifacts for the hang.

No raw logs or dumps are attached because they may contain local paths or conversation identifiers. They can be redacted and provided if maintainers specify which fields are useful.

Expected

The conversation should be transferred into the task and sent without making the desktop app unresponsive.

Workaround

Summarize/copy the ChatGPT conversation manually, create a new Codex task, and paste the summary instead of using Add to task.

Additional independent Windows reproduction with a server-backed ChatGPT conversation imported into a local Codex project. This includes a repeatable timeline and confirms that the backend can complete while the desktop UI remains unusable.

Environment

• Microsoft Windows 11 Home (Chinese), version 10.0.26200, x64
• Microsoft Store package: OpenAI.Codex 26.707.9981.0
• Bundled Codex CLI: 0.144.2
• ChatGPT.exe / Chromium version observed in the desktop process: 150.0.7871.115
• 32 GB RAM; about 19 GB free during diagnosis
• Microsoft Store reported no newer package version on 2026-07-15

Reproduction

1. Create/open a local Codex project backed by an otherwise empty Git repository.
2. Add an existing ChatGPT/web conversation to a Codex task using Add to task.
3. Send a short follow-up prompt.
4. The desktop UI becomes unresponsive.
5. Close and restart the app.
6. Reopen the project or affected task; the desktop UI becomes unresponsive again.

The imported reference expanded into a single user-message wrapper containing:

• 14 conversation messages (7 user, 7 assistant)
• 32,191 Unicode characters
• 14 legacy sandbox: links
• 22 citation markers
• references to two original attachments whose contents were not included

No conversation text or attachment data is included in this report.

Repeatability and task timeline

All timestamps are Asia/Shanghai (UTC+8), 2026-07-15.

| Local time | Local thread ID | Result |
| --- | --- | --- |
| 13:54:25 | 019f6457-2951-7502-b7a0-99d26ee2b22d | Backend turn completed in 34 seconds, but the desktop UI remained unusable |
| 14:13:11 | 019f6468-5ae4-7be3-bf2a-85035cc1a510 | Turn became interrupted after the app was closed |
| 14:19:00 | 019f646d-5272-7930-922e-2674585c59e1 | Turn became interrupted after the app was closed |

The three tasks contain the same 32,191-character imported reference.

After another restart, the app restored the first completed task. The desktop log shows:

• thread/read completed successfully in 166 ms
• thread/resume completed successfully
• the affected thread was assigned the renderer stream owner role
• the app became unusable again shortly afterward and was closed

This suggests the model request and app-server are not the only bottleneck. The persistent, thread-specific failure appears to occur while restoring or rendering the imported conversation state.

A title-generation request for one attempt also reported 13,113 input tokens and completed successfully.

Controls and diagnostics

• The local project directory contains only an empty .git directory: no source files, dependencies, or large repository content.
• Other Codex tasks remain usable.
• No new Crashpad report was generated for these attempts.
• No matching Windows Application Hang / Application Error event was captured for these attempts because the app was closed manually.
• No aligned OOM, fatal renderer, or GPU-process crash line was found in the desktop logs.
• Unrelated Git-watcher and bundled-plugin marketplace warnings also occur in healthy sessions, so they do not appear specific to this trigger.

Expected behavior

Add to task should import the conversation safely, truncate/lazy-load it if necessary, or reject it with a recoverable error. A referenced conversation must not create a persistent task that freezes the desktop app whenever the task or containing project is reopened.

Workaround

Avoid reopening the affected task. Archive/quarantine the poisoned task and manually paste a short summary into a fresh Codex task instead of using Add to task.

This reproduction also appears related to #32342 and the long-thread renderer symptoms in #19923.

+1, reproducible on macOS with ChatGPT/Codex desktop 26.707.72221 (build 5307).

Steps: select response text → More Details → continue in the side chat → Add to task → reference chip appears in the original composer → Send.

Result: the task UI becomes unresponsive. I reproduced this in both an existing long-running task and a small test task, so a large task does not appear to be required. Avoiding Add to task works around the issue.

+1 Feedback ID
019f6ba0-98eb-7622-9a49-a5c6b0868655