›_ Codex Issues
Codex Issues / #33559

Subagent tools are not exposed in ChatGPT Work or Codex Desktop

Resolved 💬 3 comments Opened Jul 16, 2026 by nerdchanii Closed Jul 16, 2026

What version of Codex CLI is running?

codex-cli 0.144.5

What subscription do you have?

ChatGPT subscription (exact plan not shown in the runtime)

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Darwin 25.5.0 arm64 arm (macOS 26.5.2)

What terminal emulator and version are you using (if applicable)?

iTerm2 3.6.10

Codex doctor report

{
  "codexVersion": "0.144.5",
  "model": "gpt-5.6-sol",
  "modelProvider": "openai",
  "authMode": "chatgpt",
  "platform": "macos-aarch64",
  "multiAgentFeatureEnabled": true,
  "latestVersion": "0.144.5"
}

The full doctor report was reviewed but is not attached because it contains local filesystem paths and state metadata. The relevant checks show that multi_agent is enabled and the current CLI version is the latest available version.

What issue are you seeing?

Native subagent tools are unavailable.

In both ChatGPT Work-hosted sessions and Codex Desktop sessions, no spawn_agent, delegation, wait-agent, or close-agent tools are exposed to the agent. When explicitly asked to delegate work or spawn a subagent, the agent reports that it cannot do so because no subagent tool is available.

This occurs even though the local Codex configuration has multi_agent = true and Codex CLI is on version 0.144.5.

What steps can reproduce the bug?

  1. Install and run Codex with codex-cli 0.144.5, ChatGPT authentication, and features.multi_agent = true.
  2. Start a ChatGPT Work-hosted session or a Codex Desktop session.
  3. Ask the agent to list its available tools.
  4. Ask it explicitly to spawn or delegate work to a subagent.
  5. Observe that no native subagent tools are exposed and the agent reports that subagents cannot be used.

Affected thread ID: 019f6a37-40c4-7c43-894b-f85889ef1ba0

The raw rollout is not attached publicly because it may contain conversation content and local metadata, but it can be provided through a secure/private diagnostic channel if requested.

What is the expected behavior?

When multi_agent is enabled, Codex should expose the native subagent tools needed to spawn, wait for, communicate with, and close subagents.

If subagents are intentionally unsupported in a runtime, Codex should expose a clear capability/status signal and document the limitation instead of silently omitting the tools.

Additional information

Related reports include #16996 (spawn policy conflicts), #18193 (tool-backed session delegation limitations), and #24069 (provider-specific subagent regression). This report concerns subagent tools being unavailable in ChatGPT Work and Codex Desktop on CLI 0.144.5.

View original on GitHub ↗

3 Comments

nerdchanii · 1 month ago

This appears to be a duplicate of, or closely related to, #32086.

After filing this issue, I found that #32086 already contains a reproduction matching this environment and symptom:

  • Codex Desktop / CLI 0.144.5
  • macOS 26.5.2 / Darwin 25.5.0 / Apple Silicon
  • features.multi_agent = true
  • gpt-5.6-sol
  • spawn_agent, wait_agent, and close_agent are not reachable

Related issue: https://github.com/openai/codex/issues/32086

Maintainers may close this issue as a duplicate if the two reports share the same underlying cause.

nemerle · 1 month ago

I've encountered the same problem and the patch/reference implementation in #32086 seems to solve the problem.

nerdchanii · 1 month ago

Follow-up after a process-level A/B investigation:

  • New upstream root-cause report: #33593
  • Separate downstream V1/Responses Lite tool-discovery bug: #32086

The original symptom in this issue was real, but it combined two layers.

In the newly isolated reproduction, two app-server processes built from the
same Codex 0.144.5 binary and using the same provider, auth mode, ChatGPT
account, and CODEX_HOME receive different /models ETags and
gpt-5.6-sol runtime metadata when only their originator differs. Both then
write to the same models_cache.json, and the app-server refresh workers repeat
the overwrite approximately every three minutes.

That upstream cache-identity/cross-process problem is now documented in #33593
with measurements, reproduction paths, code history, related PRs, a suggested
storage design, and regression-test criteria.

#32086 remains independently relevant: once a session is legitimately or
accidentally routed to V1/Responses Lite, tool_search can still be serialized
in a way that makes the deferred V1 collaboration tools unreachable.

I am closing this broad symptom report to consolidate further investigation in
those two more precise issues. This closure does not mean the behavior is
resolved.