Repository navigation
Add an option to disable remote compaction and use local fallback in the CLI #24418
Description
What variant of Codex are you using?
CLI
What feature would you like to see?
Codex CLI currently decides to use remote compaction based on the model provider. For OpenAI/ChatGPT auth this can force /compact and auto-compaction through the remote /responses/compact endpoint.
I would like a supported runtime override that disables remote compaction and lets the CLI use the existing local compaction path/fallback instead. One narrow option would be an environment variable such as:
CODEX_DISABLE_REMOTE_COMPACT=1 codexWhen the variable is set, the CLI should skip the remote compact task and return false from the same decision point that currently checks provider remote-compaction support. When it is not set, behavior should remain unchanged.
Why this would help:
- Normal Codex requests can work while the remote compact endpoint fails independently.
- In long-running CLI sessions, a failed remote compaction can make
/compactor automatic compaction unusable. - Users in proxy/VPN/firewall-sensitive environments may need to route normal API traffic differently from the ChatGPT backend compact endpoint.
- Some users prefer a deterministic local fallback over failing the active session when the remote compact task is unavailable.
Example errors seen in the CLI:
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
Error running remote compact task: context_length_exceeded
I tried setting compact_mode = "local" in ~/.codex/config.toml, but the current CLI still reported remote compact task, so this config key appears to be ignored by the current code path. A documented env/config override would make this behavior explicit.
Additional information
I searched existing issues before filing this. There are several related remote compaction failures, for example #17392, #13271, #14860, #19400, and the earlier local-fallback discussion in #10986. This request is intentionally narrower than changing the default: keep remote compaction enabled by default, but expose an explicit escape hatch for users whose sessions are blocked by the remote compact endpoint.
I also tested a minimal local patch against current main that adds the env gate at the existing should_use_remote_compact_task(...) decision point and leaves the default behavior unchanged. The local patch was small: codex-rs/core/src/compact.rs plus focused unit coverage in codex-rs/core/src/compact_tests.rs.
Activity
yui-stingray commentedon May 25, 2026
This looks like a small, bounded change. The CLI currently decides remote vs local compaction in one shared helper, and both manual and auto compaction already have a local path when that helper returns false. I do not see an existing
compact_modesetting in current main, so a documented runtime override that forces the local path would cover the failure mode without changing the default. A focused test for the fallback branch should be enough to keep the change safe.azabolo commentedon May 25, 2026
Thanks, that matches what I found locally.
I have a small patch ready that adds
CODEX_DISABLE_REMOTE_COMPACT=1at the existingshould_use_remote_compact_task(...)decision point, keeps the default behavior unchanged, and adds focused unit coverage.Would maintainers be open to a PR for this approach, or would you prefer this as a config key / different env var name?
hueifeng commentedon Jun 5, 2026
I've been hitting the same root cause — Azure /responses/compact returning 5xx/high-demand errors, which kills the entire session after exhausting retries.
I opened a detailed bug report at #25534 with a candidate patch that takes a different approach: instead of adding a manual disable switch, it falls back to local auto compaction on transient remote failures (5xx/transport errors) and preserves the error behavior for auth/4xx/usage failures. Tests included.
Patch branch: https://github.com/hueifeng/codex/tree/fix/remote-compaction-local-fallback
Both approaches share the same goal. If the team prefers a config/env-var approach (#24418), that also works — but a transparent fallback would help users who don't know to set it. Happy to consolidate either direction.
azabolo commentedon Jul 10, 2026
Update after retesting against Codex CLI 0.144.1 and inspecting current main (
1f0566d):RemoteCompactionV2is now stable and enabled by default./compactcompleted successfully. The debug trace showedapi.path="responses"andendpoint="/responses"over the Responses WebSocket transport; there was no/responses/compactrequest.CODEX_DISABLE_REMOTE_COMPACT=1patch, the same test selected the existing local summarization path, completed successfully, and also used only/responses.So the endpoint-specific failure that originally motivated this issue appears to be addressed by V2. The remaining proposal is narrower: expose a supported way to force the existing local summarization path when users need deterministic local behavior for diagnostics or provider/model compatibility, while keeping the current default unchanged.
The compaction-only patch is still limited to the shared decision helper plus focused unit coverage. Would maintainers still find a force-local override useful in the V2 architecture? If so, I can prepare the focused change and documentation as an invited PR, using whichever config/env naming you prefer.