Error running remote compact task while using 5.3codex-spark

Resolved 💬 5 comments Opened Jun 23, 2026 by martinmclee 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.142.0 with the codex desktop

What subscription do you have?

Pro 5x

Which model were you using?

5.3codex-spark

What platform is your computer?

Not provided.

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

Not provided.

What issue are you seeing?

While working in Codex, the session hit:

Error running remote compact task: {
"error": {
"message": "Your input exceeds the context window of this model. Please adjust your input and try again.",
"type": "invalid_request_error",
"param": "input",
"code": "context_length_exceeded"
}
}

and then displayed:

Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying.

The same behavior appears to align with context_length_exceeded/remote compaction failures being reported in other open issues.

What steps can reproduce the bug?

Use model 5.3codex-spark in a Codex session.
Continue with task until remote compaction is triggered (or manual /compact equivalent is invoked).
Receive Error running remote compact task and the context-window message, preventing normal continuation of the same thread.

What is the expected behavior?

Remote compaction should recover from large context state and complete or offer a safe handoff path without forcing the user to lose context by starting over.

Additional information

This appears to be another occurrence of the ongoing compaction regression around context_length_exceeded.
Please let me know if you want me to attach extra diagnostics (thread id/session id, codex version, platform, and full logs).

View original on GitHub ↗

5 Comments

martinmclee · 2 months ago

Research I found while filing this (context-management family):

Open issue around this exact message: https://github.com/openai/codex/issues/24247 (closed) — context_window error during /goal on GPT-5.5.
Open issue: https://github.com/openai/codex/issues/24078 — remote compact task always returning context_length_exceeded on v0.133.0.
Open/related: https://github.com/openai/codex/issues/24014 (closed) — app automatic context compaction fails with context_length_exceeded.

This is the first report I saw explicitly tied to 5.3codex-spark wording, so I filed separately to avoid model/variant ambiguity.

github-actions[bot] contributor · 2 months ago

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

#29302
#29041
#29319
#28816
#29142

Powered by Codex Action

martinmclee · 2 months ago

I can reproduce this on Windows with:

Desktop app: OpenAI.Codex 26.616.10790.0
CLI: codex-cli 0.142.0 (codex --version)
model: 5.3-codex-spark

It fails during startup work with:
Error running remote compact task... context_length_exceeded
and then Codex ran out of room in the model's context window...

For the same desktop+CLI on Windows, 5.5 appears stable in this same workflow. This points to a 5.3 spark-specific startup/context behavior regression in this thread.

devansh-jain-18 · 2 months ago

Adding a related datapoint from #30194 before closing it as duplicate.

Another observed shape is that compaction may appear to run, but effective context usage does not meaningfully reduce, leaving the next turn still near-full / under context pressure. So the failure mode is broader than the explicit context_length_exceeded error: compaction needs to reclaim enough usable context to continue, or clearly report that it could not.

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.