[Bug]: Grok persistent monitor stays Working after it already exited; Stop does nothing and the final recap never shows

[jameswasher]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Open T3 Code desktop (Nightly) on a Grok Build thread (grok-4.6).
2. Run a long /pr (or any turn that starts a Grok monitor with persistent: true) to watch merge-queue / deploy.
3. Let the work actually finish. On the Grok side the monitor exits (already_exited / process gone). The agent writes a final recap (merged, deploy green, Slack posted).
4. Look at the T3 thread. Try the Stop control on the still-showing monitor row.

Reproduced on every Grok /pr session that uses a persistent monitor, including The-Infinite-Actuary/core#5537 on 2026-09-18.

Expected behavior

When the Grok monitor exits, T3 should:

• drop the monitoring / Working state
• show the agent's final recap in the thread
• make Stop a no-op on an already-dead monitor, not a stuck spinner

Actual behavior

• T3 keeps showing a monitoring / Working state after the ship is done.
• Stop does not clear it. kill_command_or_subagent from a later Grok turn returns already_exited for every monitor id in the session.
• The final recap often never appears in the T3 thread. The user has to send a follow-up ("status?") to find out the work finished.

Grok finished. T3 did not.

Impact

Major degradation or frequent failure

Version or commit

T3 Code (Nightly) 0.0.41-nightly.20260915.1752

Environment

• macOS 26.6.2 (arm64)
• T3 Code (Nightly) desktop
• Grok CLI 1.0.34 (3736acbc8658) [stable]
• provider Grok Build, model grok-4.6

Logs or stack traces

Session used five persistent monitor tasks to watch a ship-driver / merge queue / Deploy run. All five later returned already_exited from kill_command_or_subagent. T3 still showed monitoring.

Monitor ids from that session (all already exited):

• 01a0b513-9876-7771-ac58-5bea3abffeab
• 01a0b53a-e2e4-7912-b857-c7c47f933db7
• 01a0b57a-792c-7d72-85a0-be465b1ee6fc
• 01a0b59e-ab36-7cb2-90d5-db3e031cf300
• 01a0b5a2-3f63-71e3-a1d4-f9b8f8b4a505

Workaround

Ask the agent for status in a new message. Ignore or refresh the stuck monitor row. Stop in the T3 UI does not help.

Additional context

Related but not the same:

• [Bug]: Grok subagents do not show correctly in the Agents panel #9892 — Grok spawn_subagent / monitor never emit task.*, so the Agents panel is empty and T3 does not know when background work is live vs done. This report is the user-visible stuck-Working / missing-recap case after a persistent monitor has already exited.
• fix(grok): emit task lifecycle for monitors and background shells #9139 (open PR) — fix(grok): emit task lifecycle for background subagents and monitors
• [orchestrator-v2] Grok v2 steer rows vanish and runs wedge on Working after reply #3580 — hung Working after a Grok reply (stranded session/prompt). Different: here the monitor process is gone.
• Grok turn stalls mid-reasoning: no tokens for 70+ minutes, UI stays Working, no turn_ended #7210 (closed) — stream died mid-reasoning. Different: here the work completed.

Please treat this as a bug against current Nightly, not as "the agent forgot to report." The recap was written; T3 did not project it, and the monitor row stayed live.

[juliusmarminge]

Looks like this is already covered by open PR #11680 (fix(grok): close background tasks when grok reports task completion) — same stuck Monitoring pill after Grok monitors exit on their own / already_exited, because T3 was not applying Grok's task_completed notice.

Tracked via Closes #12502 on that PR.