[Windows app regression] Subagent threads lose direct visibility/control and Spark is missing from spawn overrides

[Windows app regression] Subagent threads lose direct visibility/control and Spark is missing from spawn overrides

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

MSIX package version 26.803.10989.0 (Microsoft Store package, status OK).

What subscription do you have?

Not collected. The report is about the locally advertised Desktop/tool capabilities rather than an inferred subscription entitlement.

What platform is your computer?

Microsoft Windows NT 10.0.26200.8875, x64 (Windows 11 25H2).

What issue are you seeing?

Codex Desktop has regressed in two closely related subagent areas:

1. Subagent visibility and user control. Previously, spawned subagents appeared as independently visible tasks/chats. A user could open a child thread, see its selected model and reasoning effort, send a follow-up or correction directly, and change the child model/settings. In the current app, child activity is exposed only through a restricted parent-owned Subagents surface. The user cannot manage a child as a normal task, and the effective model/reasoning effort is not shown.

2. Spark routing inconsistency. gpt-5.3-codex-spark is currently advertised for normal Codex task creation and continuation, but the live spawn_agent contract exposes explicit model overrides only for gpt-5.6-sol and gpt-5.6-terra. Spark was previously used successfully for real subagent sessions on this same installation/account.

This is inconsistent with the current official subagent documentation, which says that the app surfaces each subagent thread for inspection, documents per-agent model/reasoning configuration, and includes current custom-agent examples that explicitly use gpt-5.3-codex-spark with model_reasoning_effort = "medium":

https://learn.chatgpt.com/docs/agent-configuration/subagents

What steps can reproduce the bug?

1. Open Codex Desktop and start a normal Codex task.
2. Inspect the normal task-creation model capability. gpt-5.3-codex-spark is offered, with low, medium, high, and xhigh reasoning efforts.
3. Ask the parent agent to spawn a child using gpt-5.3-codex-spark and a fresh/no-history fork.
4. Inspect the live spawn_agent schema. Its explicit model override is limited to gpt-5.6-sol and gpt-5.6-terra; Spark cannot be requested through that interface.
5. Spawn a child using any currently accepted route.
6. Open the Desktop Subagents activity surface.
7. Observe that the child is not presented with the same independent task/chat controls as before. The UI does not show the child’s effective model and reasoning effort, and the user cannot directly send a correction/follow-up or change model/settings on the child thread. Steering is available only indirectly through parent-agent control tools.

What is the expected behavior?

• Every spawned child should be surfaced as an openable, independently inspectable child task/thread.
• The child UI should show the effective resolved model and reasoning effort, not merely parent metadata or no metadata.
• After explicitly opening/selecting a child, the user should be able to send a correction, steer an active turn, continue an idle/completed child, and change supported model/reasoning settings.
• Normal-task and subagent model routing should be consistent. If Spark is available for normal Codex tasks and documented for custom subagents, it should either be an accepted spawn_agent override or the product should clearly document and surface why it is unavailable for subagents.
• If direct child input is intentionally restricted, that restriction should be explicit in the UI and documentation, with a visible effective model/effort and a first-class user control path rather than an opaque parent-only relay.

Actual behavior

• The current Desktop UI exposes a restricted parent-owned Active/Done subagent surface rather than the earlier independently controllable task/chat experience.
• Effective child model and reasoning effort are not visible.
• Direct user follow-up/steering/settings changes on child threads are unavailable; only parent-agent relay/control tools are exposed.
• Normal task creation and continuation advertise Spark, but the current spawn_agent override enum omits it.

Privacy-safe diagnostics

• Current normal task-creation/continuation contract advertises:
  • gpt-5.6-sol
  • gpt-5.6-terra
  • gpt-5.6-luna
  • gpt-5.5
  • gpt-5.4
  • gpt-5.4-mini
  • gpt-5.3-codex-spark (low, medium, high, xhigh)
• Current spawn_agent contract advertises explicit model overrides only for:
  • gpt-5.6-sol
  • gpt-5.6-terra
• Current parent-side subagent controls include follow-up/message delivery, interrupt, list, and wait operations. They do not restore the earlier direct user task/thread interaction surface.
• Privacy-safe local rollout metadata shows:
  • August 1–7: 26 actual subagent sessions used gpt-5.3-codex-spark with effort medium.
  • Latest observed Spark subagent rollout: August 7, 2026.
  • August 10–11: 157 readable actual subagent sessions used Terra, Luna, Sol, or automatic review adapters; zero used Spark.
  • No task content, project identifiers, paths, source code, or business data was inspected or included in these counts.
• Local package deployment history shows several rapid updates between July 30 and August 11. The current 26.803.10989.0 build was installed on August 11. The exact first bad build is not proven, but the observed routing cutover is between August 7 and August 10.

Custom-agent routing check

A project-scoped, read-only custom agent was defined in an isolated scratch task using the documented settings:

model = "gpt-5.3-codex-spark"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"

The current live session rejected the custom role as unknown agent_type before creating a child. This proves only that the current session’s adapter/role registry did not discover the newly added custom role. It does not prove that the backend rejected Spark model authorization, because no model-routed spawn request reached the backend. A fresh-session custom-role test would be needed to separate successful adapter discovery from backend model authorization.

No global Codex configuration was changed.

Regression timeframe

• Last known successful Spark subagent metadata: August 7, 2026.
• First observed two-day period with 157 non-Spark subagent sessions and zero Spark sessions: August 10–11, 2026.
• Current app build: 26.803.10989.0, installed August 11, 2026.
• Therefore the evidence narrows the routing regression to August 7–10, but does not identify the exact responsible app/runtime build.

Related upstream reports

• #32488 — subagent panel omissions in the Desktop app
• #33885 — MultiAgentV2 child threads reject direct corrections/steering
• #32031 — MultiAgentV2 spawn schema hides model overrides
• #31893 — documented custom agents can become unusable through the restricted schema
• #27624 — Desktop reasoning-effort handling/display regression (closed)

This report adds a current Windows build, an observed regression window, direct schema parity evidence, and a statistically bounded Spark-before/after metadata sample without exposing any private task or workspace information.

Begin by reproducing the issue on Windows using the current Desktop Subagents surface, then inspect the live spawn_agent contract and related reports #32488, #33885, and #32031. Done means child threads are independently inspectable and controllable with visible effective model and reasoning effort, and Spark routing is consistent with normal task creation.