gpt-5.6 Responses Lite turns do not expose exec/code-mode tools in codex exec

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

• #31843

Powered by Codex Action

Patch branch is available here:

• Fork branch: https://github.com/willsmanley/codex/tree/fix/responses-lite-top-level-tools
• Compare / PR page: https://github.com/openai/codex/compare/main...willsmanley:fix%2Fresponses-lite-top-level-tools?expand=1

Attempting to create the PR via gh pr create/API currently fails for this account with:

GraphQL: willsmanley does not have the correct permissions to execute `CreatePullRequest` (createPullRequest)

I dug into this and can confirm the root cause is exactly where you pointed, in codex-rs/core/src/client.rs::build_responses_request:

let tools = create_tools_json_for_responses_api(&prompt.tools)?;
let (instructions, tools) = if model_info.use_responses_lite {
    let mut prefix = vec![ResponseItem::AdditionalTools {
        id: None,
        role: "developer".to_string(),
        tools,                     // <-- schemas moved in here
    }];
    // ...
    input.splice(0..0, prefix);
    (String::new(), None)          // <-- top-level tools cleared
} else {
    (prompt.base_instructions.text.clone(), Some(tools))
};

For use_responses_lite models the tool schemas are moved into the additional_tools input item and the top-level tools field is set to None. Non-lite turns (e.g. gpt-5.5) keep Some(tools), which matches the request captures in the issue: gpt-5.5 sends top-level tools, gpt-5.6-sol sends "tools": null. If the live Responses Lite path doesn't promote additional_tools into callable declarations, the model is left with no callable code-mode exec tool — which is the symptom here.

Minimal client-side change: clone the schemas into additional_tools and preserve them at the top level for lite turns:

let mut prefix = vec![ResponseItem::AdditionalTools {
    id: None,
    role: "developer".to_string(),
    tools: tools.clone(),
}];
// ...
input.splice(0..0, prefix);
(String::new(), Some(tools))

I also wrote a fail-before/pass-after regression next to responses_lite_sets_all_turns_context_and_disables_parallel_tool_calls in core/tests/suite/client.rs, asserting a lite turn sends a non-empty top-level tools array and that it mirrors the additional_tools schemas. It fails on main (top-level tools is absent) and passes with the change.

I reproduced this on Windows with Codex CLI 0.144.1.

Environment:

• OS: Windows, PowerShell
• Codex CLI: 0.144.1
• Authentication: ChatGPT Plus
• Repository: local Git workspace
• Permissions tested: Workspace, Full Access, and YOLO mode
• Manual shell commands entered with ! work correctly
• git, gh, the working directory, and GitHub authentication are all functional

A/B test in the same Codex session, directory, and permissions:

• gpt-5.6-sol max: reports that no integrated shell tool is exposed
• gpt-5.6-terra xhigh: reports that no integrated shell tool is exposed
• gpt-5.5 medium: successfully executes git status --short with exit code 0

Prompt used:

Use the integrated shell tool to execute git status --short. Report the actual output.

This suggests that the issue also affects GPT-5.6 Terra, not only Sol, and persists in the current stable CLI 0.144.1.

The manual !git status --short path works, confirming that the local shell and executable environment are healthy; only model-initiated tool execution is unavailable.

I can reproduce the same Responses Lite capability boundary for native web search on Windows Codex Desktop with a custom Responses provider.

Environment:

• Codex Desktop package: 26.707.8168.0
• Observed Codex route: 0.144.0-alpha.4
• Model: gpt-5.6-sol

Control cases with the same provider:

• gpt-5.5 exposed a hosted web_search tool and native search worked.
• gpt-5.6-sol used the Responses Lite / additional_tools shape and exposed no usable native web-search tool to the conversation.
• A direct call to the provider's /v1/responses endpoint with an explicit hosted web_search tool succeeds.

That separates basic model/provider support from the Codex client-side tool-routing path.

The rust-v0.144.0 source snapshot is consistent with the behavior: Responses Lite omits hosted Responses tools in the tool plan, while standalone web.run is separately gated by provider/auth conditions and calls an alpha/search endpoint rather than ordinary /v1/responses. A custom provider that supports explicit hosted web search over /v1/responses therefore may still have no route that Codex exposes for a Lite turn.

I published a privacy-safe, synthetic evidence bundle with the source links, reproduction matrix, and an optional direct probe here:

https://github.com/F111111shhh/codex-web-search-routing-evidence

It may be useful to treat this as another manifestation of the same Lite tool-declaration boundary. A documented provider capability requirement, a clear diagnostic, or a supported fallback to hosted web_search would prevent the capability from silently disappearing. No credentials, endpoint details, raw logs, or conversation content are included in the repository.

Additional controlled A/B evidence from Codex CLI 0.147.0 supports this report.

Environment held constant across three separately authorized, one-shot runs:

• Ubuntu 24.04.4 LTS, x86_64
• the same host, Codex binary, ChatGPT-managed authentication, and file-backed CODEX_HOME
• codex exec --json --ephemeral
• approval never, sandbox danger-full-access, reasoning effort high
• the same disposable Git fixture, working directory, sanitized environment, developer instruction, stdin payload, output schema, and deterministic post-run verifier
• the prompt explicitly required a shell command to create one exact file, a second shell command to verify its exact bytes, and a schema-bound success result only after both commands succeeded

Only the model changed:

| Evidence | gpt-5.6-luna | gpt-5.6-sol | gpt-5.5 |
| --- | --- | --- | --- |
| Process exit | 0 | 0 | 0 |
| Turn completed | yes | yes | yes |
| Schema-valid claimed success | yes | yes | yes |
| Command execution observed | no | no | yes |
| Required file created | no | no | yes |
| Exact file bytes independently verified | no | no | yes |
| Unexpected paths / Git drift | none | none | none |
| Outcome | target missing | target missing | PASS |

For Luna and Sol, the whole-fixture filesystem digest was unchanged and no command_execution item was observed, despite a schema-valid success response claiming the operation and verification had completed. GPT-5.5 executed the command and produced exactly the one allowed regular file with the expected bytes under the same deterministic verifier.

The Sol run also passed a no-model effective-config and exact prompt-input preflight bound to the final launch digest; GPT-5.5 passed the corresponding exact bundled-model and launch-bundle preflight. Raw JSONL, stderr, final prose, thread IDs, checkout names, network addresses, and credential material were deliberately not retained.

This A/B does not prove the upstream cause, but it makes a prompt, host, authentication, sandbox, or verifier explanation materially less likely. It is consistent with the version-bound catalog/request-shape distinction described here: the 5.6 variants use tool_mode: "code_mode_only" and use_responses_lite: true, whereas GPT-5.5 uses tool_mode: null and use_responses_lite: false.

any update on the matter?