pingdotgg / pingdotgg/t3code

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

Open
#12,502 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
23k
Forks
5.9k
Avg merge
11h 14m
Merged PRs (30d)
357

Description

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:

  • #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.
  • #9139 (open PR) — fix(grok): emit task lifecycle for background subagents and monitors
  • #3580 — hung Working after a Grok reply (stranded session/prompt). Different: here the monitor process is gone.
  • #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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in apps/server and reproduce a persistent Grok monitor using the listed steps, tracing how monitor exit, task state, and the final recap reach the thread. Use the provided already_exited monitor results to compare process state with the displayed Working row. Done means an exited monitor clears Working, the recap appears, and Stop is harmless after exit.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
65/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.