›_ Codex Issues
Codex Issues / #33008

Referenced chats (@-mention) injects entire prior conversation as a single message — permanent renderer freeze on every launch + unrecoverable compact deadlock

Open 💬 5 comments Opened Jul 14, 2026 by tingxueren
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

"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:

  1. 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 inside v8::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.
  2. 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

  1. Have a long-running chat (hundreds of turns).
  2. In a Codex Desktop session, use @-mention to reference that chat, send the message.
  3. The turn may complete once, but the session file now contains a single ~1 MB response_item/user_message.
  4. Quit and reopen the app → renderer spins at 100% CPU 1–2 min after launch, UI frozen. Reproduces on every launch (auto-resume).
  5. codex resume <session-id> from CLI → remote compact fails with context_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).
  • lsof on 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)

  1. Quit the app; move the offending rollout file out of ~/.codex/sessions/YYYY/MM/DD/ → app starts normally.
  2. To salvage the thread: truncate the oversized text/message fields in the two giant jsonl lines to a short placeholder, restore the file, then codex 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

  • #32342 (pasting a large ChatGPT conversation crashes the app — likely same rendering weakness, manual paste path)
  • #25251 (large thread → sustained 100%+ CPU)
  • #24089 (resume-time remote compact fails with context_length_exceeded)

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32342

Powered by Codex Action

czc6666 · 1 month ago

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-*.jsonl locally 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 · 1 month ago

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 · 1 month ago

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
  • Product: ChatGPT desktop app, Codex mode
  • Subscription: ChatGPT Pro
  • Platform: macOS 26.5.2 (25F84), Apple Silicon
  • ChatGPT app version: 26.715.72359 (5718)
  • Bundled Codex version: 0.145.0-alpha.30
  • Model: GPT-5.6 Sol
  • Incident time: 2026-07-23 17:50, UTC+8
Steps to reproduce
  1. Open Codex mode.
  2. Select a GitHub project and create a new task.
  3. Add an existing ChatGPT/Codex conversation as referenced context.
  4. Enter a relatively short prompt.
  5. Click Send.
Actual behavior
  • The prompt remains visible in the composer.
  • The Send button keeps showing a pending/spinning state.
  • The entire application becomes unresponsive: sidebar items, profile controls, and window controls no longer respond.
  • No visible error appears and no normal task record is created.
  • There is no state change for at least 15 seconds; the app has to be force-quit.
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 · 1 month ago

Additional confirmed reproduction on the current macOS Codex Desktop build:

  • ChatGPT/Codex Desktop: 26.721.41059 (build 5848)
  • Bundled Codex CLI/app-server: 0.146.0-alpha.3.1
  • Platform: macOS / Apple Silicon

The desktop app read two referenced Codex threads and serialized their full visible histories into the new prompt.

Measured conservative lower bound after JSON serialization:

  • Referenced thread A: 488,484 characters
  • Referenced thread B: 630,346 characters
  • Combined referenced-chat payload: 1,225,174 characters
  • App-server limit: 1,048,576 characters

Desktop logs show thread/read succeeding for both referenced threads, followed by turn/start failing within 48 ms with JSON-RPC -32602.

An independent probe against the same bundled app-server confirmed the detailed error:

Input exceeds the maximum length of 1048576 characters.
input_error_code: input_too_large

The Desktop-specific regression is that the renderer creates an optimistic in-progress turn before turn/start succeeds. When the request is rejected, that turn remains visually stuck as Pending instead of being rolled back or displaying the real input_too_large error.

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:

  1. Apply a shared size budget, summarization, or deterministic truncation before referenced chats are injected.
  2. Validate the final expanded input before creating the optimistic turn.
  3. Always roll back Pending/in-progress state when turn/start fails.
  4. Surface error.data.input_error_code and the actual/max character counts to the user.

I intentionally omitted raw logs, local paths, and thread IDs from this public comment.