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

[willsmanley]

Summary

codex exec with gpt-5.6-sol can report that shell/code-mode tools are unavailable, while the same prompt works with gpt-5.5.

The issue appears to be the Responses Lite request shape: for use_responses_lite=true models, Codex currently moves client tool schemas into an input[0] item of type additional_tools and omits top-level tools. In the live 5.6 path I tested, those additional_tools are not exposed as callable tools, so the model does not see the public code-mode exec tool.

Environment

• Codex CLI: codex-cli 0.144.0
• OS: Ubuntu 26.04 x86_64
• Model that works: gpt-5.5
• Model that fails: gpt-5.6-sol

Reproduction

This works with gpt-5.5:

codex exec --model gpt-5.5 --json --ephemeral --skip-git-repo-check --sandbox read-only 'please run ls and tell me if it works'

Observed: Codex emits a command execution item and runs /bin/bash -lc ls successfully.

This fails with gpt-5.6-sol:

codex exec --model gpt-5.6-sol --json --ephemeral --skip-git-repo-check --sandbox read-only 'please run ls and tell me if it works'

Observed assistant message:

I can’t run `ls` because no shell execution tool is available in this session.

Request capture

Using a local Responses capture provider, the gpt-5.5 request includes top-level tools:

{
  "model": "gpt-5.5",
  "tool_names": [
    "exec_command",
    "write_stdin",
    "list_mcp_resources",
    "list_mcp_resource_templates",
    "read_mcp_resource",
    "update_plan",
    "request_user_input",
    "request_plugin_install",
    "apply_patch",
    "view_image",
    "tool_search",
    "web_search"
  ]
}

The gpt-5.6-sol request has no top-level tools:

{
  "model": "gpt-5.6-sol",
  "tools": null,
  "parallel_tool_calls": false
}

But input[0] contains the code-mode tools as additional_tools:

{
  "type": "additional_tools",
  "role": "developer",
  "tool_names": ["exec", "wait", "request_user_input", "collaboration"]
}

The exec additional tool description includes nested tools.exec_command(...), but the live model does not appear to receive exec as callable.

Expected behavior

gpt-5.6-sol should be able to call the public code-mode exec tool, and from there call nested tools.exec_command(...), so simple shell prompts work as they do with gpt-5.5.

Suspected cause

codex-rs/core/src/client.rs has a Responses Lite branch in build_responses_request that inserts ResponseItem::AdditionalTools { tools, ... } into input, then sends tools: None at the top level.

If the live Responses Lite path does not promote additional_tools into callable tool declarations, then the model is left with no callable code-mode tools.

Candidate fix

Keep the existing additional_tools item for the Responses Lite input contract, but also send the same client-executed tool schemas in top-level tools.

I have a small patch ready that:

• clones the generated tool schemas into additional_tools
• preserves tools: Some(tools) at the top level for Responses Lite turns
• updates HTTP and websocket regression tests to assert both locations match

Related issues

These are related to the same 5.6 custom exec/code-mode tool path, but appear to describe crashes after an exec tool call is emitted rather than the model not seeing exec at all:

• macOS x86_64: Codex CLI 0.142.5 SIGTRAP on gpt-5.6-sol shell tool call #30861
• codex-cli 0.142.5 on macOS 26.5.1 Intel crashes when the server sends functions.exec. The crash occurs in V8 OS::SetPermissions with SIGTRAP. It reproduces with unified_exec, code_mode, and code_mode_only explicitly disabled. #31475

[github-actions]

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

• GPT-5.6 models get no tools in read-only sandbox (codex exec -s read-only says it has no shell/file tools) #31843

Powered by Codex Action

[willsmanley]

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)

[pa-arth]

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.