Remote CLI auto-compact times out on gpt-5.5 long sessions

Resolved 💬 4 comments Opened May 26, 2026 by kuangyonglin Closed Jun 29, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.133.0

What subscription do you have?

Not specified in this report.

Which model were you using?

gpt-5.5

What platform is your computer?

Linux 5.15.0-134-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

Windows, connecting to the remote Linux host over SSH.

Codex doctor report

What issue are you seeing?

In long-running remote CLI sessions, automatic context compaction can time out and the session becomes difficult to continue.

The relevant remote log line is:

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

Related observation: after upgrading the remote CLI from 0.130.0 to 0.133.0, an old codex app-server process had to be restarted because the TUI initially connected to the stale 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 automatic remote compaction timeout still appears to be a separate long-session reliability issue.

What steps can reproduce the bug?

SSH into a remote Linux host.

Start Codex CLI in a large project:

cd ~/Simulation/OpenFOAM-dev
codex
Use gpt-5.5.

Work in the same remote session until the context becomes large enough for automatic compaction.

Let automatic compaction run.

Observe that remote compaction can fail with compact_error=request timed out.

Thread id:

Unavailable / redacted.

What is the expected behavior?

Codex should either:

complete automatic context compaction successfully, or
fail quickly with a recoverable error and preserve enough state for the user to continue, or
expose a reliable context usage indicator so users can manually summarize before auto-compaction is triggered.

Additional information

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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

#24323

Powered by Codex Action

sinduke · 3 months ago

I have the save question "019e6350-0449-7491-afe1-1e1d5212c7e3"

kuangyonglin · 3 months ago

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

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.

etraut-openai contributor · 1 month ago

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.