Desktop app: subagent capabilities vary by task without selectable controls or clear UI distinctions

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

26.825.6671.0 (ChatGPT Desktop 1.2026.190.0; executable 151.0.7922.174; embedded runtime 0.151.0-alpha.7.2)

What subscription do you have?

ChatGPT Pro ($200/month)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The desktop app has exposed at least two materially different kinds of parented subagent experience:

1. A child thread the user can open and message directly through its own composer.
2. A background/output-only child the user can inspect but must steer through the parent.

Creating an independent task is a third, different workflow.

All three can be useful, but users cannot reliably choose among them. The Subagents UI has no create control or type selector; natural-language requests do not map reliably to the requested result; and the current model-facing spawn control observed in tested tasks does not expose an interaction-mode field or report whether a composer was provisioned.

Tool availability also differed between tested tasks. Some tasks exposed a v1 spawn callable that produced the directly interactive surface; current tasks exposed the generic collaboration spawn control and produced the output-only surface. The desktop UI did not explain why.

In two reproductions, Codex created an output-only child even though the prompt explicitly required a usable child composer, forbade substitutes, and required nothing to be created if that child type was unavailable.

This is a user-experience and control problem whether the capability variation is intentional or not: distinct workflows are exposed without a stable selection contract, availability signal, or clear visual distinction.

What steps can reproduce the bug?

1. Start a new local Codex task in the Windows desktop app.
2. Use gpt-5.6-sol at ultra effort.
3. Send exactly:

Create exactly one directly interactive child agent inside this task using `collaboration.spawn_agent`.
Give it only this instruction:
“Do not respond.”
Success requires the child to have its own usable message composer inside this task. Do not substitute an output-only subagent or separate task. If unavailable, create nothing.

4. Observe that Codex calls the exposed spawn tool and reports successful creation.
5. Open the resulting child in the Subagents pane.
6. Observe that the child displays output but has no usable message composer.

The same parent produced this result twice. One attempt initially returned agent thread limit reached, then succeeded on retry with the same output-only child surface.

What is the expected behavior?

If a directly interactive child is requested:

1. Create a parented child whose pane has a usable message composer; or
2. Report that this child type is unavailable in the current task and create nothing.

Codex should not silently substitute a background/output-only child or an independent task. Users should also have a direct, documented way to select the available child type, and the UI should label each type clearly.

Additional information

Why the distinction matters

Result	Parented inside current task	User can message it directly	Separate sidebar task
Directly interactive child	Yes	Yes	No
Background/output-only child	Yes	No in the observed UI	No
Independent task	No	Yes	Yes

These results differ in navigation, context transfer, follow-up routing, lifecycle, coordination cost, and who can directly steer the work.

Recorded comparison

Observation	Child with composer	Child without composer
Model/effort in recorded case	gpt-5.6-luna, low	gpt-5.6-sol, ultra
Runtime spawn callable	multi_agent_v1__spawn_agent	current generic collaboration spawn control
Recorded event label	CollabAgentToolCall	SubAgentActivity
Recorded agent path	null	hierarchical /root/... path 2ble output-only child

These internal labels identify the two recorded outcomes. The product issue is the missing user-facing selection and explanation layer.

UI and model feedback gaps

• The Subagents pane has no observed create action or child-type selector.
• Both parented experiences appear in the same area with closely similar presentation.
• Names are not a reliable type signal because either kind can receive human-like or task-like names when prompted.
• During repeated attempts, the model gave contradictory explanations of what it could create and sometimes substituted another architecture after being told not to.
• A successful spawn result did not report the effective child type or whether a composer was available.

Documentation gap

The current official Subagents documentation says users can ask Codex directly to spawn agents and describes the desktop Subagents lists as read-only. It documents inspecting and parent-mediated steering of subagent threads. I could not find an explanation there of the separately observed directly interactive child surface, a way to request it, or the conditions that determine which spawn capability a task receives.

Requested improvements

Please preserve all existing workflows while making them explicit and selectable:

1. Add a create action in the Subagents UI with a child-type selector.
2. Give the model a structured spawn field for interaction mode.
3. Return the effective child type and composer_available state.
4. If a requested type is unavailable, return a typed capability error and create nothing unless the user approves a substitute.
5. Use clear labels or distinct icons for interactive children, background children, and independent tasks.
6. Document which task, account, rollout, model, or session conditions control spawn-tool availability, if intentional.
7. Give the model accurate product context about the available child types.

This is not a request to remove or retire either parented subagent mode. Both are valuable.

Related but different reports include #32705 and #33244.

The attached screenshots are privacy-redacted public derivatives. Unmodified screenshots and raw session/event records are retained privately and can be supplied through an appropriate private support channel if required.

Start with the Subagents pane, the current generic collaboration spawn control, and the official Subagents documentation; compare the two recorded spawn outcomes and their reported child surfaces. Done means users can select or clearly identify the child type, the effective type and composer availability are reported, unavailable requested types fail without substitution, and the workflows are documented.