[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
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
- Install Codex desktop 26.422.x on Apple Silicon.
- Select GPT-5.5.
- Keep default plugins enabled so tool descriptions cross the ~10% context threshold that auto-enables \
tool_search\+ \defer_loading\. - Work normally until the conversation approaches the compact threshold.
- 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
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
same
fuck openai
give back my money!
I hit the same failure and traced it to the Codex Rust remote-compact request construction path.
Root cause from the current
maincode path:codex-rs/core/src/compact_remote.rswithtool_router.model_visible_specs()directly.codex-rs/core/src/session/turn.rs, so compact can senddefer_loading=truetool specs to/responses/compactin a shape the endpoint rejects with: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:
model_visible_specs_for_prompt(...).remote_compact_filters_deferred_dynamic_tools, that compares the normal-turn and remote-compacttoolspayloads and verifies the deferred dynamic tool spec /defer_loadingmarker do not leak into compact requests.Validation run locally:
I tried opening an upstream PR from that fork branch, but the repo currently blocks it for my account with
CreatePullRequestpermission 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.Based on blame and related PR history, cc @pash-openai and @sayan-oai as the most relevant maintainers for this specific failure surface:
[tool search] support namespaced deferred dynamic tools), which introduced/owns the deferred dynamic-tool filtering path incodex-rs/core/src/session/turn.rs.enable tool search over dynamic tools) and merged #18413; blame also points to the dynamic-tooltool_searchentry construction incodex-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.