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

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.

Reproduce the Windows Desktop 0.148.0-alpha.9 session with the reported config.toml settings and inspect the assembled tool list, then compare it with the working CLI 0.146.0 session. Trace the Desktop/app-server tool assembly and feature-flag handling; done means a normal parent session has exec and local file tools, or can use a worker that does.