Repository navigation
Referenced chats (@-mention) injects entire prior conversation as a single message — permanent renderer freeze on every launch + unrecoverable compact deadlock #33008
Description
"Reference chats" (@-mention a chat) serializes the ENTIRE prior conversation into a single user message — permanent renderer freeze + unrecoverable context blowout
Environment
- ChatGPT Desktop for macOS, Codex Framework 150.0.7871.115
- macOS 15 (Apple Silicon)
- codex-cli 0.144.1 (used for recovery/verification)
Summary
Using the "@-mention a chat" (Referenced chats) feature with a large prior conversation injects the entire serialized transcript as ONE user message (885 KB in my case, beginning with ## Referenced chats with Codex: followed by the full JSON-serialized conversation). No size cap, no summarization. One oversized message then defeats every safety layer at once:
- Desktop UI permanently freezes. The renderer's JS main thread enters an infinite loop rendering the giant message (100% CPU, confirmed by
sample: all samples insidev8::Script::Run). Because the app auto-resumes the last session on every launch, killing the app, resetting the Chromium profile (~/Library/Application Support/Codex), and rebooting the machine all reproduce the freeze within 1–2 minutes of startup. There is no in-app way to escape. - Context window is unrecoverable. 885 KB ≈ 200k+ tokens in a single message. On resume, remote compaction deadlocks:
Error running remote compact task: Codex ran out of room in the model's context window— compaction works at message granularity and cannot split a single message that is larger than the window, so it can never free space.
Steps to reproduce
- Have a long-running chat (hundreds of turns).
- In a Codex Desktop session, use @-mention to reference that chat, send the message.
- The turn may complete once, but the session file now contains a single ~1 MB
response_item/user_message. - Quit and reopen the app → renderer spins at 100% CPU 1–2 min after launch, UI frozen. Reproduces on every launch (auto-resume).
codex resume <session-id>from CLI → remote compact fails withcontext_length_exceeded-style error; thread unusable.
Evidence
- Session rollout jsonl: line lengths 885,457 and 885,369 bytes (
response_item message+event_msg user_message), content starts with:
## Referenced chats with Codex:\nThis is untrusted background context from Codex chats.\n[{"title":"...","priorConversation":{"conversation":[... sample <renderer-pid>: 100% of samples on the main thread inside V8 script execution (pure JS loop, no I/O wait).lsofon the app-server process shows the same rollout file reopened for write on every app launch (auto-resume), explaining why no restart helps.
Workaround (for other users hitting this)
- Quit the app; move the offending rollout file out of
~/.codex/sessions/YYYY/MM/DD/→ app starts normally. - To salvage the thread: truncate the oversized
text/messagefields in the two giant jsonl lines to a short placeholder, restore the file, thencodex resume <session-id>from the CLI.
Suggested fixes
- Cap / summarize referenced-chat content before injection (never emit a single message anywhere near the context window size).
- Renderer: virtualize/clip rendering of pathologically long messages.
- Compaction: handle single-message-larger-than-window (truncate or drop with notice) instead of deadlocking.
- Startup: detect a renderer that spins immediately after auto-resume and offer safe mode / skip-resume, so users are not permanently locked out.
Related issues
- Inserting the ChatGPT conversation into Codex will cause Codex to crash. #32342 (pasting a large ChatGPT conversation crashes the app — likely same rendering weakness, manual paste path)
- Codex Desktop: opening a large thread causes sustained 100%+ CPU until app restart #25251 (large thread → sustained 100%+ CPU)
- Old Desktop rollouts resume into impossible context usage and remote compact fails with context_length_exceeded #24089 (resume-time remote compact fails with context_length_exceeded)
Activity
github-actions commentedon Jul 14, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
czc6666 commentedon Jul 14, 2026
I built a small, unofficial, browser-local read-only checker after reading this report and related large-thread incidents:
https://czc6666.github.io/codex-thread-health/
It does not repair or modify a session and does not claim to diagnose the OpenAI backend. It streams a selected
rollout-*.jsonllocally and produces a sanitized structural receipt for signals such as a >500 KB record, inline binary payloads, an unfinished latest turn, and large observed context. The file is not uploaded; the receipt excludes the filename, path, prompt, commands, tool output, model name, and conversation text.Your published 885 KB boundary is represented as a synthetic test case, but I have not tested against your private rollout and do not need you to share it. If you are willing to try the page locally, the useful validation question is narrow: would this receipt have changed your decision before reopening/resuming the affected thread, or is it merely restating information you already had? A “not useful” answer is equally valuable.
Source and limitations:
https://github.com/czc6666/codex-thread-health
Please do not post raw rollout content or private paths in feedback.
Sigurd00 commentedon Jul 17, 2026
Additional report: Codex Desktop freezes when loading chats that contain references to other chats.
Edit: I asked the chat to make a bug report and it automatically commented here. This was my prompt:
"Make a bug report to openai on this page: https://github.com/openai/codex/issues
The bug is that the codex desktop application freezes when loading chats that have references to other chats."
The bug can be reproduced without a big long running chat. The chat I referenced was actually only 5 turns.
idaibin commentedon Jul 23, 2026
Additional macOS reproduction: entire app freezes immediately after sending a task with a referenced chat
I can reproduce this in Codex mode in the unified ChatGPT desktop app.
Environment
Steps to reproduce
Actual behavior
Expected behavior
The task should be submitted normally. If the referenced conversation is too large, the app should reject, summarize, or truncate it with a recoverable error instead of freezing the renderer.
Triggering reference
The task referenced an existing conversation titled:
rustzen-admin 功能集成建议The manually entered prompt itself was short. The freeze occurred immediately after Send, before any visible agent execution began. A screen recording captured the behavior.
This appears closely related to this issue and #31966. I do not currently have a feedback/session ID or process sample for this reproduction.
ERerGB commentedon Jul 29, 2026
Additional confirmed reproduction on the current macOS Codex Desktop build:
26.721.41059(build5848)0.146.0-alpha.3.1The desktop app read two referenced Codex threads and serialized their full visible histories into the new prompt.
Measured conservative lower bound after JSON serialization:
488,484characters630,346characters1,225,174characters1,048,576charactersDesktop logs show
thread/readsucceeding for both referenced threads, followed byturn/startfailing within 48 ms with JSON-RPC-32602.An independent probe against the same bundled app-server confirmed the detailed error:
The Desktop-specific regression is that the renderer creates an optimistic in-progress turn before
turn/startsucceeds. When the request is rejected, that turn remains visually stuck as Pending instead of being rolled back or displaying the realinput_too_largeerror.This reproduced four times on the same build.
This appears to connect the unbounded referenced-chat expansion reported here with the hard app-server input limit in #20742.
Suggested P0 fixes:
turn/startfails.error.data.input_error_codeand the actual/max character counts to the user.I intentionally omitted raw logs, local paths, and thread IDs from this public comment.