›_ Codex Issues
Codex Issues / #38960

Windows Desktop 0.148-alpha.9: parent /root session has no exec, only wait + collaboration tools

Open 💬 2 comments Opened Aug 17, 2026 by lisu108
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop, bundled CLI 0.148.0-alpha.9 (originator: Codex Desktop, source: vscode).

Desktop app build previously reported in local runtime env as 26.810.52044.

Desktop runtime still present at:

%LOCALAPPDATA%\OpenAI\Codex\bin\e305f1c75d8da435\codex.exe

Rolling the npm CLI back to @openai/codex@0.146.0 (codex-cli 0.146.0) fixes CLI sessions. The Desktop app does not follow that rollback and stays on 0.148.0-alpha.9.

What subscription do you have?

Custom Responses-compatible provider (model_providers.ccswitch, wire_api = "responses", local proxy). Not a ChatGPT-only first-party session. Model: gpt-5.6-terra.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 10 Home China)

What issue are you seeing?

Every new Codex Desktop coding session is assembled as a broken /root orchestrator:

  1. Developer prompt includes You are /root, the primary agent in a team of agents... and collaboration tools (spawn_agent, send_message, followup_task, wait_agent, interrupt_agent, list_agents).
  2. A later instruction says do not spawn sub-agents unless explicitly asked.
  3. The parent agent is not given local file/command tools. In particular, exec is missing.

The model's actual tool surface on Desktop is only:

  • functions.wait
  • functions.request_user_input (Plan mode only)
  • collaboration.followup_task
  • collaboration.interrupt_agent
  • collaboration.list_agents
  • collaboration.send_message
  • collaboration.spawn_agent

There is no exec, no filesystem tools, no search/edit tools. Workspace permissions are fine (the project directory is writable). The agent then loops on functions.wait with invalid float args (1.0 / 10000.0) and eventually says it cannot read files.

This is not a repo-permission problem. It is a Desktop session tool-assembly bug.

Same machine, same ~/.codex/config.toml, CLI 0.146.0 works: it still receives the /root text, but exec is present and can read/write files.

config.toml already disables:

[features]
multi_agent = false
collaboration_modes = false

Desktop ignores this and still injects the /root collaboration surface without exec.

What steps can reproduce the bug?

  1. Use Codex Desktop on Windows with a custom Responses provider (wire_api = "responses").
  2. Open a normal coding task (not an explicit multi-agent / team entry).
  3. Ask: 列出你当前这一轮可用的所有工具
  4. Observed: only wait, Plan-only request_user_input, and collaboration tools. No exec.
  5. Ask to read any local file or 测试本地文件读写能力.
  6. Observed: agent tries functions.wait repeatedly and cannot read/write files.

Recorded Desktop sessions:

  • 01a0094e-5caf-7ed0-ab00-2798a4747c4e — user asked to read work/selections.json; agent only called functions.wait.
  • 01a00943-e967-7ff3-8c2d-e5cf711f693b — same missing-tool diagnosis on a new Desktop thread.
  • 01a00e65-fa9c-7c40-a973-07f1e22bbcb1 (2026-08-17T06:25:59Z) — originator: Codex Desktop, cli_version: 0.148.0-alpha.9. Agent listed only wait/collaboration tools, then failed a local IO test with functions.wait.

Working CLI control on the same machine, minutes earlier:

  • 01a00e63-362a-7bf2-9b31-b679e35e3949 (2026-08-17T06:22:58Z) — originator: codex-tui, cli_version: 0.146.0. Same prompt family (You are /root), but exec was available and used (custom_tool_call name=exec).

Desktop does not pick up the rolled-back npm CLI. It keeps using its private runtime under %LOCALAPPDATA%\OpenAI\Codex.

What is the expected behavior?

A normal Desktop coding session should expose local tools to the parent agent, at least exec (and the usual file/search/edit path), even if collaboration tools are also present.

If Desktop is going to force /root + collaboration tools:

  • the parent must still have exec, or
  • it must be allowed/required to spawn a worker that has exec.

The current combination is a deadlock: parent has no local tools, and it is told not to spawn sub-agents.

Rolling Desktop/app-server back to a 0.146-era tool assembly, or honoring multi_agent = false / collaboration_modes = false, should restore a single-agent Desktop session with exec.

Additional information

This looks related to, but stricter than, https://github.com/openai/codex/issues/37718 , https://github.com/openai/codex/issues/37075 , and https://github.com/openai/codex/issues/37376 .

In #37718 the captured request still included exec in the tools array, and the reporter said last-good Desktop was 0.147.0-alpha.1.2. On this machine, Desktop 0.148.0-alpha.9 does not expose exec to the parent at all. CLI 0.146.0 is a clean workaround; Desktop remains broken after CLI rollback.

Redacted config shape:

model_provider = "ccswitch"
model = "gpt-5.6-terra"

[model_providers.ccswitch]
name = "OpenAI"
base_url = "http://<redacted-local-proxy>:8080/v1"
wire_api = "responses"
requires_openai_auth = false

[features]
goals = true
multi_agent = false
collaboration_modes = false

Please treat this as a Desktop/app-server tool-assembly regression on Windows, not a workspace ACL issue.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 11 days ago

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

  • #37718

Powered by Codex Action

LG-CN · 10 days ago

I can reproduce this on a newer Codex Desktop build as well.

Environment:

  • Windows x64
  • Codex Desktop 26.814.5167.0
  • Bundled CLI: 0.148.0-alpha.15
  • Custom Responses-compatible provider (wire_api = "responses")

The Desktop issue is still present on 0.148.0-alpha.15.

A fresh Desktop session cannot successfully execute a simple Get-Location. The parent agent attempts to use exec, fails, and then falls back to spawning sub-agents.

In my reproduction, the fallback recursively reached at least depth 3:

/root
  /run_ps
    /run_get_location
      /run_get_location

The deepest recorded worker had:

originator: Codex Desktop
cli_version: 0.148.0-alpha.15
thread_source: subagent
depth: 3

It did not produce a successful local exec/tool call.

I also performed an A/B test using the npm CLI with the same configuration.

CLI 0.147.0 — broken

The tool call is emitted as:

{
  "type": "function_call",
  "name": "functions__exec",
  "arguments": {
    "cmd": "Get-Location",
    "shell": "powershell"
  }
}

Codex immediately returns:

unsupported call: functions__exec

CLI 0.146.0 — working

After rolling back to:

npm install -g @openai/codex@0.146.0

the same test instead uses:

type: custom_tool_call
name: exec

and dispatches through:

const result = await tools.exec_command({
    cmd: "Get-Location",
    shell: "powershell",
    login: false
});

Get-Location then executes successfully.

The behavior on the same machine is therefore:

CLI 0.146.0                -> exec works
CLI 0.147.0                -> functions__exec -> unsupported call
Desktop 0.148.0-alpha.15   -> still broken; falls back to recursive sub-agent spawning

This suggests the regression may be related to the tool assembly / dispatch path introduced after 0.146.0, particularly the difference between:

custom_tool_call: exec

and:

function_call: functions__exec

This also confirms that the issue still reproduces with bundled CLI 0.148.0-alpha.15, which is newer than the 0.148.0-alpha.9 version originally reported here.