[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.

Compact fails in CLI and Codex VS Code Extension #19009 — Compact fails in CLI and VS Code Extension
Experimental feature check disabling app startup #19279 — Experimental feature check disabling app startup
[Desktop] White screen infinite loop due to workspace_dependencies feature enablement error on Pro account (v26.422.21637) #19295 — White screen on v26.422.21637 (Pro)
GPT-5.5 not usable in Codex App for remote projects (works in CLI) #19370 — GPT-5.5 not usable in Codex App for remote projects

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

Remote compaction fails when using gpt-5.5 because /responses/compact does not appear to support the model #19400
GPT-5.5 Codex session hits unrecoverable compaction failure around ~220k tokens despite advertised 400k context #19386
Context compaction not working #19441

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 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.

@pash-openai

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 [tool search] support namespaced deferred dynamic tools #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 enable tool search over dynamic tools #18263 (enable tool search over dynamic tools) and merged [tool search] support namespaced deferred dynamic tools #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.

fix: filter dynamic deferred tools from model_visible_specs (#19771)

fix: filter dynamic deferred tools from model_visible_specs (openai#1…

feat(runtime,ui,desktop): defer tool schemas natively where the wire can

Navigation Menu

Repository navigation

[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 #19486

Severity: Blocker / P0

Environment

Error

Reproduction

Likely root cause

Why the obvious workarounds do not work

Impact

Requested fix

Related

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[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 #19486

Description

Severity: Blocker / P0

Environment

Error

Reproduction

Likely root cause

Why the obvious workarounds do not work

Impact

Requested fix

Related

Activity

github-actions commented on Apr 25, 2026

21888 commented on Apr 25, 2026

FengYeeLx commented on Apr 25, 2026

sf-jin-ku commented on Apr 26, 2026

sf-jin-ku commented on Apr 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions