Activity

1. 3022244459

   added

   bugSomething isn't workingSomething isn't working

   on May 12, 2026
2. etraut-openai

   added

   contextIssues related to context management (including compaction)Issues related to context management (including compaction)

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on May 12, 2026
3. kuangyonglin commented on May 26, 2026

   

   kuangyonglin

   on May 26, 2026

   More actions

   I am seeing what looks like the same class of failure on a remote Codex CLI session.

   Environment:

   Remote Codex CLI: codex-cli 0.133.0
   Remote platform: Linux 5.15.0-134-generic x86_64 x86_64
   Local client: Windows, connecting to the remote host over SSH
   Model: gpt-5.5
   tmux: not installed on the remote host
   

   The session is started from a large project on the remote host:

   cd ~
   codex
   

   In a long-running remote session, automatic remote compaction failed with this log line:

   2026-05-25T15:17:58.193082Z ERROR codex_core::compact_remote: remote compaction failed turn_id=<redacted> last_api_response_total_tokens=211465 all_history_items_model_visible_bytes=699124 estimated_tokens_of_items_added_since_last_successful_api_response=0 estimated_bytes_of_items_added_since_last_successful_api_response=0 model_context_window_tokens=Some(258400) failing_compaction_request_model_visible_bytes=713888 compact_error=request timed out
   

   After upgrading the remote CLI from 0.130.0 to 0.133.0, I also had to restart stale remote codex app-server / codex app-server proxy processes. Before restarting them, the TUI connected to the old app server and failed with:

   Invalid request: invalid type: string ":workspace", expected internally tagged enum PermissionProfileSelectionParams
   

   Restarting the stale app-server fixed that startup/protocol error, but the remote auto-compaction timeout above still appears to be a separate long-session reliability issue.

   Current workaround:

   • keep Codex CLI on the latest stable version;
   • avoid letting gpt-5.5 long sessions reach automatic compaction;
   • manually write a digest before the context gets too large;
   • start a fresh session from that digest;
   • switch to a lower model temporarily if a long session is already near compaction failure.
4. kuangyonglin commented on May 28, 2026

   

   kuangyonglin

   on May 28, 2026

   More actions

   Workaround report: compact hang improved after pinning Desktop/VS Code extension versions

   I am reporting a workaround that made my long-running remote Codex sessions usable again. I do not think this proves the root cause is fully fixed, but it may help narrow the regression window.

   Symptom

   In long-running Codex sessions, especially with gpt-5.5, automatic context compaction could hang or fail around the /responses/compact step. The session would stop making progress during "Automatically compacting context" / "thinking", or eventually fail with an error such as:

   Error running remote compact task: stream disconnected before completion
   

   or:

   compact_error=request timed out
   

   Normal responses and websocket traffic could still work, while the compaction path remained unreliable.

   Environment

   • Windows x64 host
   • Codex Desktop on Windows
   • Codex VS Code extension on Windows
   • Remote Linux host accessed through SSH
   • Remote Codex CLI: codex-cli 0.134.0
   • Model where the issue was most visible: gpt-5.5 prox5

   Workaround that is currently stable for me

   I downgraded/pinned the local client components to:

   • VS Code extension: openai.chatgpt-26.506.31004-win32-x64
   • Codex Desktop: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0.Msix
   • Remote Codex CLI: kept at codex-cli 0.134.0

   Current result

   After pinning the local Desktop/VS Code extension versions above, my remote Codex workflow is usable again.

   This looks like a workaround, not a confirmed fix. Based on other related reports, I suspect the failure may involve a combination of:

   • Desktop / VS Code extension / app-server version compatibility
   • /responses/compact being a separate and more fragile path than normal response websocket traffic
   • gpt-5.5 remote compaction behavior
   • large retained tool outputs or very large assembled history

   Related issues I found

   • #22309: remote compact task stuck/disconnected
   • #24618: /responses/compact can hang 30-60 minutes or return 504 while normal websocket responses work
   • #23951: retry remote compaction v2 requests, included in 0.134.0
   • #21911: VS Code extension 26.506.31421 feature negotiation mismatch with Rust app-server
   • #22091: Desktop 26.506.31421 rapidly bloats context from retained tool outputs and can freeze old sessions
   • #19400: gpt-5.5 remote compaction may be brittle when the compact endpoint does not support the same model path as normal responses

   Request

   Could maintainers confirm whether there was a Desktop/VS Code extension regression after the 26.506.x builds, or whether /responses/compact has different timeout/model handling from the normal response websocket path?

   It would also help if Codex exposed:

   • the exact compact transport being used,
   • compact retry/timeout state,
   • whether the compact request is using the active model or a separate compact model,
   • and a way to recover the thread after compact failure instead of leaving it stuck.
5. Kenmege commented on Jun 8, 2026

   

   Kenmege

   on Jun 8, 2026

   More actions

   Adding a current high-signal data point from macOS where this is reproducible enough that I had to install a local guard.

   Environment

   • Codex CLI: codex-cli 0.137.0
   • Platform: macOS arm64, Mac mini
   • Model/config: model = "gpt-5.5", model_reasoning_effort = "xhigh"
   • Effective model window observed in session telemetry: 258400
   • Failure point from local handoff telemetry: 195306 / 258400 input tokens, ratio 0.7558
   • Endpoint in the visible failure: https://chatgpt.com/backend-api/codex/responses/compact
   • Network route at time of diagnosis: route to chatgpt.com via utun5, MTU 1380; Surfshark WireGuard process active. Public IP and home path are intentionally redacted.
   • macOS system proxy/env proxy: no HTTP(S) proxy env vars, scutil --proxy only reported passive FTP, so this appears route-level VPN/tunnel behavior rather than an HTTP proxy.

   What happens

   When Codex reaches remote compaction, the remote compact stream can fail with:

   Error running remote compact task: stream disconnected before completion:
   error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
   

   The important operational problem is not only that the stream disconnects. It is that the session can be left non-recoverable/inert from the user’s perspective unless the user already has an out-of-band handoff. For long coding sessions, this is effectively context loss.

   Useful comparison/control

   On the same Mac mini and same VPN/tunnel route, Claude Code Sonnet 4.6 can compact successfully near very high context usage. That does not prove Codex should share Claude's implementation, but it does suggest this machine/network path is not generally incapable of long coding-agent compaction. Codex's /backend-api/codex/responses/compact request/stream/recovery path appears more fragile.

   Local mitigation I had to add

   I added a local PreCompact guard that:

   1. Writes a bounded durable handoff before compact.
   2. Allows remote compact only if the payload is still relatively small.
   3. Emits {"continue": false} before the hard danger zone so Codex does not attempt the fragile huge compact stream.
   4. Rehydrates a fresh session from a small handoff if the local guard had to stop the session.

   Current local mitigation thresholds:

   model_auto_compact_token_limit = 145000
   CODEX_HANDOFF_HARD_ABORT_TOKEN_LIMIT = 175000
   CODEX_HANDOFF_HARD_ABORT_RATIO = 0.68
   

   This makes Codex more survivable locally, but it is a workaround. The upstream behavior should be better.

   Upstream ask

   Please make remote compact resilient and recoverable:

   • If /backend-api/codex/responses/compact stream disconnects, retry/resume the compact operation instead of wedging the thread.
   • If retry/resume is not possible, fall back to a client-visible durable recovery packet or local summary and let the user continue in a new/forked session without losing task state.
   • Trigger compaction early enough, or use chunking/upload/resumable semantics, so a large coding session does not depend on one long fragile streaming request.
   • Preserve enough state for recovery: latest user request, active CWD/repo root, git status, recent decisions/events, and exact compact failure reason.
   • Surface request IDs / compact operation IDs in CLI/Desktop logs so users can report a specific failed compact attempt.

   Expected behavior: failed remote compact should degrade into retry/fallback/recovery, not force the user to terminate and manually reconstruct context.
6. etraut-openai commented on Jun 29, 2026

   

   etraut-openai

   on Jun 29, 2026

   Contributor

   More actions

   Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use /feedback and open a new bug report.
7. etraut-openai

   closed this as completedon Jun 29, 2026