[Bug]: Grok top-level MCP thread stays status=running after final reply (Monitor command_execution rows still running) on 0.1.7 #30304

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. On T3 Code Nightly 0.1.7-nightly.20261103.4119 (Linux), from an orchestrator agent, create a top-level thread with MCP t3_thread_launch targeting provider Grok (grok-4.6, high reasoning).
2. Let that Grok agent do real work: spawn short-lived native subagents, run shell commands, and start several Monitor watches (for example watching background job completion).
3. Wait until the agent writes its final assistant reply and reports back to the parent via t3_thread_send. Native subagents finish earlier and show idle / completed.
4. Do not interrupt, cancel, restart, or send follow-ups to the child thread.
5. Read the child with t3_thread_list / t3_thread_read.

Observed once in normal use (not a minimal deterministic repro). Related earlier symptom on pre-0.1.7 builds: delegate_task Grok children also stayed running / cancelled after finishing.

Expected behavior

After the Grok turn posts its final assistant message and the provider session/prompt ends, the thread/run/provider turn become terminal (completed). UI/API status leaves "working" / running. Leftover background monitors either settle with the turn, or remain visible as background work without leaving the whole run stuck as an active turn.

Actual behavior

About 50+ minutes after the final assistant message:

• t3_thread_read / t3_thread_list: thread status: "running", activeRunId set, latest run status: "running", completedAt: null, pendingRequestCount: 0.
• Activity ends on a completed final assistant_message; hasMore: false.
• Provider event log: session/prompt started at turn start, then session/prompt failed with errorTag: "Interrupt" at the same timestamp as the final assistant item (same end-event shape noted in closed [Bug]: Grok delegated child stays "running" after its turn ends; parent never notified #15888).
• Projection: orchestration_v2_projection_runs and provider turn stay running with completed_at = NULL. Two native subagents are completed (finished ~45 minutes before the final reply). Three command_execution rows remain status: "running"; their titles are Monitor watches (job-completion monitors). root_turn node stays running.
• No restart/interrupt/cancel was attempted on this thread while collecting evidence.

Impact

Major degradation or frequent failure

Version or commit

0.1.7-nightly.20261103.4119 (cefb544af3c9). Desktop/nightly install on the machine matched that runtime. A newer nightly (0.1.7-nightly.20261103.4138) exists but was not the installed version when this thread ran.

Timing on this host (local CET):

• App/runtime update to 0.1.7-nightly.20261103.4119: ~17:50–17:52 CET
• Stuck thread created: 2026-11-03T17:01:43.061Z (~18:01 CET) — after the update
• Final activity / session/prompt end: 2026-11-03T17:55:05Z (~18:55 CET)

So this is not a pre-update leftover thread. Public release notes for 4119 do not literally say "Grok threads stuck on working"; earlier fixes for related Grok finalize/background holds include #22709 / closed #15888 and #11680 / closed #12502.

Environment

• OS: Linux (CachyOS), x64 desktop
• T3 Code: Nightly 0.1.7-nightly.20261103.4119
• Provider: Grok Build / ACP, model grok-4.6
• Thread creation: MCP t3_thread_launch from an orchestrator agent (creationSource: "mcp", top-level, not a delegate_task child)

Logs or stack traces

Sanitized projection summary only (no prompts, paths, or project contents):

thread.status=running  activeRunId set  pendingRequestCount=0
run.status=running  completed_at=NULL
provider_turn.status=running  completed_at=NULL
session/prompt: started -> failed errorTag=Interrupt (at final assistant_message time)
subagents: 2 completed (finished well before final reply)
turn_items still running: 3 x command_execution titled as Monitor job-completion watches
root_turn node: running

Workaround

Not tried here (intentionally avoided interrupt/cancel/restart so the stuck state stayed intact for the report).

Related issues (searched; not duplicates of this path)

• Closed [Bug]: Grok delegated child stays "running" after its turn ends; parent never notified #15888 / fix fix(server): delegates finish when their leftover work settles, and Grok commands stop holding runs open #22709 — Grok delegate_task child stays running after turn end; background commands holding finalize. Same session/prompt Interrupt end-event shape; this report is a top-level MCP t3_thread_launch thread on 0.1.7, with Monitor command_execution rows still running.
• Closed [Bug]: Grok persistent monitor stays Working after it already exited; Stop does nothing and the final recap never shows #12502 / fix(grok): close background tasks when grok reports task completion #11680 — Grok persistent monitor stays Working after exit.
• Open [Bug]: Grok subagents finish, but the parent stays on Working #21060 — Grok subagents finish but parent stays Working (MultiResult / wait_all). Here native subagents were already completed long before the final reply.
• Open Grok turns held open by stalled background subagents show no waiting state, and steering only supersedes attempts #17159 — held open by stalled background subagents. Here subagents completed; hold appears tied to Monitor command rows.
• Open Muse Code background monitors aren't shown as pending work; the thread looks finished and the monitor can't be stopped #19061 — Muse monitors (opposite UX: thread looks finished while monitor lives).