Repository navigation
Remote CLI auto-compact times out on gpt-5.5 long sessions #24538
Description
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.
Activity
github-actions commentedon May 26, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
sinduke commentedon May 26, 2026
I have the save question "019e6350-0449-7491-afe1-1e1d5212c7e3"
kuangyonglin commentedon May 28, 2026
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/compactstep. The session would stop making progress during "Automatically compacting context" / "thinking", or eventually fail with an error such as:or:
Normal responses and websocket traffic could still work, while the compaction path remained unreliable.
Environment
codex-cli 0.134.0gpt-5.5Workaround that is currently stable for me
I downgraded/pinned the local client components to:
openai.chatgpt-26.506.31004-win32-x64OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0.Msixcodex-cli 0.134.0Current 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:
/responses/compactbeing a separate and more fragile path than normal response websocket trafficgpt-5.5remote compaction behaviorRelated issues I found
#22309: remote compact task stuck/disconnected#24618:/responses/compactcan hang 30-60 minutes or return 504 while normal websocket responses work#23951: retry remote compaction v2 requests, included in0.134.0#21911: VS Code extension26.506.31421feature negotiation mismatch with Rust app-server#22091: Desktop26.506.31421rapidly bloats context from retained tool outputs and can freeze old sessions#19400:gpt-5.5remote compaction may be brittle when the compact endpoint does not support the same model path as normal responsesRequest
Could maintainers confirm whether there was a Desktop/VS Code extension regression after the
26.506.xbuilds, or whether/responses/compacthas different timeout/model handling from the normal response websocket path?It would also help if Codex exposed:
etraut-openai commentedon Jun 29, 2026
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
/feedbackand open a new bug report.