›_ Codex Issues
Codex Issues / #22890

Codex Web remote compaction fails with context_length_exceeded from mobile session

Resolved 💬 4 comments Opened May 15, 2026 by bmanczak Closed Jun 29, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

While using Codex Web from the ChatGPT mobile app to control a Codex session running on a Mac laptop, automatic context compaction failed and the thread showed this error:

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"
  }
}

The UI showed "Compacting context" immediately before the error. The user had tapped "Please keep going"; instead of compacting the context and continuing, the session surfaced the raw context_length_exceeded response.

What steps can reproduce the bug?

  1. Open a Codex session from the ChatGPT mobile app and control Codex running on a laptop.
  2. Continue a thread until context compaction is triggered automatically.
  3. In this case, the thread included Gmail tool calls and attachment-read output immediately before compaction. The visible UI redacted the tool output, so the exact payload is not included here.
  4. Ask Codex to keep going after compaction starts.

Observed result: remote compaction fails with context_length_exceeded.

Session/thread identifier visible in local attachment path: 019e2d36-f1ac-7630-8c1a-630348907a4e.

What is the expected behavior?

Codex Web should compact the thread successfully, or if the context is too large to compact, it should recover with an actionable UI state instead of failing the compaction request with context_length_exceeded.

Additional information

  • Host laptop platform: macOS 26.4.1, Darwin 25.4.0 arm64 arm.
  • Local Codex CLI version on the host: codex-cli 0.120.0.
  • Mobile client: ChatGPT app on a phone, controlling the Codex session remotely.
  • Active model/reasoning setting shown in the screenshot: 5.5 High.
  • Screenshot time: 2026-05-15 around 21:55 local time.
  • Possibly related to CLI report #20866, but this report is specifically for the Codex Web/mobile control path.
  • Suggested labels: bug, codex-web, context, mobile. Reporter account could not apply labels because the repository rejected AddLabelsToLabelable for this account.

View original on GitHub ↗

4 Comments

bmanczak · 3 months ago

The automatic Issue Deduplicator workflow for this issue failed before it could post results.

Manual related-issue check:

  • #20866 has the same context_length_exceeded remote compaction error signature, but is reported for CLI/Windows.
  • #19547 and #22031 are also remote compaction failures, though their visible error is stream disconnected before completion.

Keeping this issue open because the report is specifically for the Codex Web / ChatGPT mobile-app control path, which does not appear to be covered by the exact existing context_length_exceeded report.

Snailflyer · 3 months ago

This looks like a remote-compaction recovery problem, not only a context-size problem. If the mobile/web path triggers compaction and then receives context_length_exceeded, the user needs a recoverable state rather than a raw model error.

I would split the failure into three checkpoints:

  1. What transcript/tool-output slice was selected for the compact task.
  2. Whether redacted or attachment-derived tool output was included in the compact input even though it was hidden in the UI.
  3. Whether the host session still has a valid pre-compact continuation point after the compact task fails.

For mobile control, the worst case is silent loss of authority: the phone says “keep going,” compaction fails, and the user cannot tell whether the local host session can still continue from the pre-compact state. A clear compaction_failed_but_session_resumable vs compaction_failed_needs_manual_trim state would make this much easier to recover from.

2batsloverandomartifactromps-dotcom · 2 months ago

I am seeing the same failure family with Codex mobile/remote-control plus long-running /goal work: auto-compaction does not reliably compact and continue; it can leave the thread effectively broken or unrecoverable rather than surfacing a recoverable compact failure.

I added fresh Windows Codex Desktop /goal evidence on #24544, including a compact boundary and later token-accounting events that appear saturated/corrupted (input_tokens=0, total_tokens == model_context_window) in active goal sessions. The mobile symptom reported by the user appears to be the remote-control/mobile surface of the same underlying problem: compaction/replay/goal state is not being restored robustly after the compact step.

Cross-reference: #24544 comment id 4665791415.

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.