[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:
- 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.
- Spark routing inconsistency.
gpt-5.3-codex-sparkis currently advertised for normal Codex task creation and continuation, but the livespawn_agentcontract exposes explicit model overrides only forgpt-5.6-solandgpt-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?
- Open Codex Desktop and start a normal Codex task.
- Inspect the normal task-creation model capability.
gpt-5.3-codex-sparkis offered, withlow,medium,high, andxhighreasoning efforts. - Ask the parent agent to spawn a child using
gpt-5.3-codex-sparkand a fresh/no-history fork. - Inspect the live
spawn_agentschema. Its explicitmodeloverride is limited togpt-5.6-solandgpt-5.6-terra; Spark cannot be requested through that interface. - Spawn a child using any currently accepted route.
- Open the Desktop Subagents activity surface.
- 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_agentoverride 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_agentoverride enum omits it.
Privacy-safe diagnostics
- Current normal task-creation/continuation contract advertises:
gpt-5.6-solgpt-5.6-terragpt-5.6-lunagpt-5.5gpt-5.4gpt-5.4-minigpt-5.3-codex-spark(low,medium,high,xhigh)- Current
spawn_agentcontract advertises explicit model overrides only for: gpt-5.6-solgpt-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-sparkwith effortmedium. - 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.0build 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.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Thanks — I reviewed both suggested issues. #38029 is related to them, but it is not a duplicate of either one:
gpt-5.3-codex-spark: normal task creation still advertises Spark, the livespawn_agentcontract does not, and local privacy-safe rollout metadata shows Spark subagents through Aug 7 followed by zero Spark subagents across 157 readable Aug 10–11 child sessions. It also includes the separate Desktop child-thread visibility/control regression.So I am keeping #38029 open. I have retained #37540 and #37536 as related references rather than treating either as the canonical duplicate.
Additional Windows Desktop reproduction on a newer build:
26.814.5167.0model: "gpt-5.6-terra"reasoning_effort: "high"Observed behavior:
Within the same general subagent workflow, some opened child threads show a model/reasoning metadata box beneath the conversation, while others omit that box entirely. In the explicit-spawn case above, the user could not consistently inspect the requested/effective
gpt-5.6-terra / highvalues from the child-thread UI.This reproduction removes one possible ambiguity: the missing metadata is not limited to children that merely inherit defaults from the parent or
[agents]configuration. Both values were supplied explicitly at spawn time.I cannot conclude from the UI omission alone that routing ignored the requested values; this evidence is specifically about inconsistent Desktop presentation/inspectability of the resolved child model and reasoning effort.
Expected behavior:
The workflow was initiated by a skill, but the child was created through the normal Codex subagent spawn path; the skill itself does not render the Desktop metadata panel. No private task content, repository paths, or child thread IDs are included here.