[P0 / Blocker] Remote compact task fails 100% with "tools.defer_loading requires tools.tool_search" — GPT-5.5 unusable at context limit, no client-side workaround

Resolved 💬 5 comments Opened Apr 25, 2026 by thughy Closed Apr 27, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Severity: Blocker / P0

Codex becomes unusable the moment any non-trivial conversation reaches the auto-compact threshold. 100% reproducible. No viable client-side workaround — rolling back the desktop app does not help because the failing call is constructed server-side.

This bug effectively makes the headline GPT-5.5 launch experience on Codex desktop dead on arrival for anyone running the default plugin set.

Environment

  • Codex desktop (macOS, Apple Silicon)
  • Reproduced on 26.422.30944 (current)
  • Reproduced on 26.422.21459 after manual rollback — identical failure
  • Model: GPT-5.5, reasoning effort \xhigh\
  • Plugins enabled (default-ish set): \github\, \browser-use\, \documents\, \spreadsheets\, \presentations\, \computer-use\

Error

As soon as the conversation hits the compact threshold:

\\\
Error running remote compact task: {
"error": {
"message": "Invalid Value: 'tools.defer_loading'. Deferred tools require tools.tool_search.",
"type": "invalid_request_error",
"param": "tools.defer_loading",
"code": null
}
}
\
\\

The session stalls. Every retry reproduces the same 400. The conversation cannot progress.

Reproduction

  1. Install Codex desktop 26.422.x on Apple Silicon.
  2. Select GPT-5.5.
  3. Keep default plugins enabled so tool descriptions cross the ~10% context threshold that auto-enables \tool_search\ + \defer_loading\.
  4. Work normally until the conversation approaches the compact threshold.
  5. The remote compact endpoint returns the 400 above — every time, with no recovery path.

Likely root cause

The server-side compact task (\chatgpt.com/backend-api/codex/responses/compact\) rebuilds the Responses API payload with \defer_loading\ on individual tool entries but omits the paired \tool_search\ entry at the top level of the \tools\ array. The Responses API then rejects its own internally-constructed request. This regression coincides with \"tool discovery enabled by default\" in the recent changelog.

In other words: the server is failing its own schema validation against itself.

Why the obvious workarounds do not work

  • Rolling back the desktop client (30944 → 21459): identical failure. Compact is remote — client version is irrelevant.
  • Starting new threads: resets context, but any substantive session hits the same wall again.
  • Switching to GPT-5.4: \defer_loading\ was introduced in 5.4, so it almost certainly exercises the same path.
  • Disabling plugins until tool descriptions drop under the ~10% threshold is the only thing that might avoid it — i.e., asking paying users to disable advertised features to get the product to function.

Impact

  • GPT-5.5 + Codex desktop is non-functional for any user with the default plugin set as soon as a conversation fills.
  • This is the flagship model from last week's launch.
  • There is no preserved-functionality workaround.
  • The fix does not require a client release — it is a pure server-side correction in the compact-task request builder.

Requested fix

Either:

  • (a) Include \tool_search\ in the rebuilt compact request whenever any tool entry carries \defer_loading\, or
  • (b) Strip \defer_loading\ from tool entries in the rebuilt compact request when \tool_search\ is intentionally omitted.

Please prioritize. This is a top-of-funnel regression on a paid flagship model.

Related

  • #19009 — Compact fails in CLI and VS Code Extension
  • #19279 — Experimental feature check disabling app startup
  • #19295 — White screen on v26.422.21637 (Pro)
  • #19370 — GPT-5.5 not usable in Codex App for remote projects

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

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

  • #19400
  • #19386
  • #19441

Powered by Codex Action

21888 · 4 months ago

same

FengYeeLx · 4 months ago

fuck openai
give back my money!

sf-jin-ku · 4 months ago

I hit the same failure and traced it to the Codex Rust remote-compact request construction path.

Root cause from the current main code path:

  • Normal model turns already filter deferred dynamic tool specs before sending the Responses request.
  • Remote compact builds its prompt in codex-rs/core/src/compact_remote.rs with tool_router.model_visible_specs() directly.
  • That bypasses the normal-turn deferred-tool filtering in codex-rs/core/src/session/turn.rs, so compact can send defer_loading=true tool specs to /responses/compact in a shape the endpoint rejects with:
Invalid Value: 'tools.defer_loading'. Deferred tools require tools.tool_search.

I prepared a minimal fix branch here:

https://github.com/openai/codex/compare/main...sf-jin-ku:jin/fix-remote-compact-deferred-tools?expand=1

What the branch changes:

  • Extracts the normal-turn tool visibility filtering into model_visible_specs_for_prompt(...).
  • Reuses that helper from remote compact, so compact gets the same filtered tool payload normal turns already use.
  • Adds a regression test, remote_compact_filters_deferred_dynamic_tools, that compares the normal-turn and remote-compact tools payloads and verifies the deferred dynamic tool spec / defer_loading marker do not leak into compact requests.

Validation run locally:

just fmt
just fix -p codex-core
just clippy -p codex-core -- -D warnings
cargo test -p codex-core --test all remote_compact_filters_deferred_dynamic_tools -- --nocapture

I tried opening an upstream PR from that fork branch, but the repo currently blocks it for my account with CreatePullRequest permission errors. If this direction matches the intended fix, a maintainer can either invite/enable the PR path for the branch above or apply the patch directly.

sf-jin-ku · 4 months ago

Based on blame and related PR history, cc @pash-openai and @sayan-oai as the most relevant maintainers for this specific failure surface:

  • @pash-openai authored #18413 ([tool search] support namespaced deferred dynamic tools), which introduced/owns the deferred dynamic-tool filtering path in codex-rs/core/src/session/turn.rs.
  • @sayan-oai authored #18263 (enable tool search over dynamic tools) and merged #18413; blame also points to the dynamic-tool tool_search entry construction in codex-rs/core/src/tools/spec.rs.

The compact side of the issue is that remote compact bypasses that normal-turn filtering and calls tool_router.model_visible_specs() directly. The compare branch above applies the existing normal-turn filter to remote compact too.