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

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:

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

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.

Fix two bugs blocking Codex agentic coding — tool calls now execute

Complete the /v1/models schema — it unlocks Desktop agentic coding

fix(harness-codex): set default model back to `gpt-5.5` due to upstre…

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?

Possible workaround: increase `node_repl` startup timeout when using a local Ollama model

I am using Codex through Xcode with a local Ollama model (qwen3.5:122b-a10b) on macOS.

I was experiencing intermittent failures where the model request would fail almost immediately with:

input[0]: unknown input item type: "additional_tools"

The logs showed that the bundled node_repl and cua_repl MCP servers were being started at the beginning of the thread:

node_repl: starting
cua_repl: starting

The request could then fail before either MCP server had reported that it was ready.

I initially suspected that the JavaScript/Computer Use integration itself was incompatible with the local model. Disabling node_repl, however, caused the model request to fail immediately, so I left it enabled.

The default configuration contained:

[mcp_servers.node_repl]
startup_timeout_sec = 120

I changed this to:

[mcp_servers.node_repl]
startup_timeout_sec = 360

After doing this, the next request took longer to initialise, but subsequently completed normally. In particular, a request involving a large source-context file, which had previously produced broken output, completed coherently.

This suggests that, at least in this environment, the 120-second MCP startup timeout may be too short for the node_repl / Computer Use environment to initialise reliably.

There may also be an authentication or Computer Use initialisation step involved, which can produce longer delays.

Environment

macOS Tahoe 26.6
Apple M1 Ultra
128 GB unified memory
Codex CLI/runtime: 0.154.0-alpha.6.2
Host: Xcode
Model provider: local Ollama
Model: qwen3.5:122b-a10b
MCP servers involved: node_repl, cua_repl

Important qualification

This is currently an empirical workaround rather than a confirmed explanation of the underlying failure. I have not yet established exactly what node_repl is waiting for during startup, nor whether the additional_tools error is directly caused by the timeout.

However, increasing the timeout from 120 to 360 seconds changed the behaviour from repeated immediate/broken requests to a request that waited for initialisation and then completed successfully.

It may therefore be worth trying a larger startup_timeout_sec before disabling node_repl when investigating similar local-model/Xcode failures.

Title: Related diagnostic evidence: codex exec 0.154.0 completes without observed command execution

We observe a related symptom through a custom MCP wrapper launching Codex CLI on Linux. The installed CLI reports 0.154.0; binary provenance and the model actually selected for the affected turn have not been independently attested.

The wrapper launches exec with JSON output, approval never, read-only sandbox, ephemeral mode and a fixed repository workspace. No model override is supplied. The child environment contains only HOME, CODEX_HOME, PATH, LANG and NO_COLOR.

Two separately authorized read-only attempts ended without the required reader result. In the instrumented second attempt, the process exited 0 and completed, but no command_execution start/completion/failure item was observed. Its final text stated TOOL_UNAVAILABLE; this is model text, not a native capability error. No successful execution is inferred.

The runtime and project binding were checked separately. The configured environments.toml was absent. No sandbox broadening or model/provider switch was attempted. These observations do not attest effective features, model tool mode, provider request shape or actual tool registration.

At the release-tag source commit 6b9826e, core/src/client.rs::build_responses_request still places tool schemas in AdditionalTools and clears top-level tools for use_responses_lite. This is consistent with the branch discussed in #31894, but we do not yet know whether our failed turn used it.

Could maintainers advise:

Does gpt-5.6 Responses Lite turns do not expose exec/code-mode tools in codex exec #31894 remain applicable to CLI 0.154.0 and the current managed authentication route?
What supported, bounded diagnostic can attest the selected model, effective tool mode, and tool declaration route for an exec turn without exposing prompts, credentials or raw rollouts?
Is there a released fix or documented workaround for this precise path, and how should applicability be verified before changing a runtime?

No private repository names, hostnames, paths, task/thread IDs, credentials, raw logs or source contents are attached. This is related evidence, not a confirmed duplicate or a deterministic minimal reproducer.

Navigation Menu

Repository navigation

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

Summary

Environment

Reproduction

Request capture

Expected behavior

Suspected cause

Candidate fix

Related issues

Possible workaround: increase `node_repl` startup timeout when using a local Ollama model

Environment

Important qualification

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Reproduction

Request capture

Expected behavior

Suspected cause

Candidate fix

Related issues

Activity

github-actions commented on Jul 9, 2026

willsmanley-archive commented on Jul 9, 2026

pa-arth commented on Jul 9, 2026

netwalkerai commented on Jul 12, 2026

F111111shhh commented on Jul 13, 2026

ch9ddar commented on Aug 13, 2026

StErMi commented on Aug 27, 2026

paniuncle commented on Sep 3, 2026

8i8 commented on Sep 16, 2026

Possible workaround: increase node_repl startup timeout when using a local Ollama model

Environment

Important qualification

skk-sec commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Possible workaround: increase `node_repl` startup timeout when using a local Ollama model