Codex App side conversation can misclassify an explicit new-task request as prohibited subagent delegation

Open 💬 1 comment Opened Jul 31, 2026 by roli-lpci

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

26.721.81911

What subscription do you have?

ChatGPT Pro ($200/month)

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

In a Codex App side conversation, an explicitly authorized request to create a separate Codex task was refused twice on the stated basis that side conversations could not spawn or interact with agents. After the request was re-examined, the thread-management tool surface exposed codex_app.create_thread, and creating the separate task succeeded immediately.

This is a user-visible false refusal: the request was for a separate app-level task, not for a collaboration-tree subagent. The observed behavior is consistent with an instruction/tool-contract ambiguity that lets those two primitives be conflated. This report does not establish an internal root cause.

What steps can reproduce the bug?

  1. Start a Codex App side conversation.
  2. Explicitly ask the assistant to create a separate Codex task (not to spawn a collaboration subagent).
  3. Observe a refusal that treats the request as unavailable because it is coming from a side conversation or because agent/subagent creation is prohibited.
  4. Ask the assistant to inspect the available tool contract for creating a new/background thread.
  5. When codex_app.create_thread is available, invoke it with the same explicit authorization.
  6. Observe that a separate task is created.

Observed twice in one side conversation; independently unconfirmed. The issue can be triaged without private thread IDs or raw traces.

What is the expected behavior?

When a user explicitly requests a separate Codex task and the app-level thread-creation capability is available, the assistant should distinguish that request from collaboration-tree subagent delegation and either create the task or explain a concrete capability/authorization failure.

Additional information

Related but not duplicate: #16996 concerns precedence between repository instructions and subagent-spawn policy. This report concerns a side conversation incorrectly treating an explicitly authorized, app-level new-task request as that different primitive.

Also related, but different: #25990 and #29223 report missing or legacy thread-management tool surfaces; #26227 discusses side-chat persistence. Here, the task-creation capability was discoverable and succeeded after the false refusal.

Suggested design direction: make app-level task creation and collaboration-tree subagent delegation distinct in both tool descriptions and refusal reasoning. If the assistant sees ambiguous “agent” language, it should resolve the target primitive against the available capability contract rather than infer a prohibition.

View original on GitHub ↗

1 Comment

roli-lpci · 26 days ago

Reproduced again on 2026-08-01 in a later Codex App side conversation.

The user explicitly asked for a separate app-level Codex session. The assistant initially refused because it conflated the side-conversation prohibition on collaboration-tree subagents with app-level task creation. After the user corrected that distinction and asked it to inspect the available capability, codex_app.create_thread was available and created the separate task immediately; the new task entered the active state.

This recurrence matches the original report: the capability was present and authorized, but refusal reasoning selected the wrong primitive. No private thread IDs or raw traces are needed to reproduce it.