spawn_task chip's "running task" badge never clears once the (in-thread-injected) work is verifiably complete — distinct from the closed stuck-spinner cluster

What happened

A spawn_task chip was created (task_id: task_aeac18a5), then clicked. Per #91820, clicking injected the chip's prompt into the same open thread rather than spawning a new session — confirmed at the time via list_sessions/ListAgents showing no new session anywhere. The work described by the chip was then carried out entirely in that thread: several file edits, native test runs, and a commit (c6fcfd2). Since then, in the same still-open session, substantial further unrelated work has happened — two more GitHub issues filed (#97304, #97305), comments added, multiple file edits elsewhere. Rechecked just now, freshly, via both ListAgents and list_sessions: no running agent, no running session, anywhere on the account. The activity badge nonetheless still reads "1 running task."

Why this is not a duplicate of the closed stuck-spinner cluster (#60094, #60095, #63389, #73267, #73400, #74950)

Those six reports all describe the same shape: a real subagent or background task actually ran, actually finished, and the UI's completion-notice path failed to fire, leaving a stale "Running" badge behind — a dropped or missed event. That's a plausible race condition with a plausible fix (make the completion event more reliable).

This report describes a structurally different situation. Per #91820, clicking a spawn_task chip does not create any session or task the platform can track through a lifecycle at all — the work just becomes ordinary conversation turns in the existing session. There is no spawned unit of work to emit a completion event in the first place. So this isn't "the finish signal got dropped somewhere" — there was never a finish signal to drop. A fix that only makes existing completion notifications more reliable (the fix those six reports would call for) would not touch this case, because reliability doesn't matter when the event doesn't exist to begin with. The chip's own internal "started"/"running" state needs a way to resolve independent of a session-completion event, specifically for the case where #91820's bug means no such session was ever created.

Distinct from this reporter's own related filings

• #97304 — this same badge is also wrong at chip-creation time, before any click. That's a pre-start bug.
• #91820 (existing) — describes the click-time behavior (in-thread injection instead of spawning).
• This report is the third phase: the badge's failure to ever clear afterward, once work is unambiguously done.

Reproduced

CLI 2.1.281, desktop app, macOS 15.7.9, 2026-09-25/26. Session created 2026-09-25T15:36:31Z, still open at time of filing (2026-09-26T00:08Z+) — roughly 8.5 hours, spanning the chip's full lifecycle and substantial unrelated subsequent work, all while the badge has not changed.

Supporting Data

• Session ID: local_90eca63f-a1f2-44c3-b8e6-eeb5ee1de57d
• spawn_task chip's task_id: task_aeac18a5
• Session created: 2026-09-25T15:36:31.108Z
• Session last activity (at time of filing): 2026-09-26T00:08:14.547Z (session still open, not restarted or compacted since the chip was created)
• Exact spawn_task tool result at creation time (verbatim): "Noted (position 1, task_id: task_aeac18a5) ... Currently pending: task_aeac18a5 ... Continue your current work."
• Exact dismiss_task tool result when later attempting to clear it (verbatim): "Task task_aeac18a5 was already started by the user — it's no longer pending and can't be withdrawn. Nothing was changed." — i.e., the chip's own backing state agrees it was started, but offers no path to mark it finished.
• Commit produced by the work the chip described: c6fcfd2 (in the mr-esp32 repo), confirming the described work was completed, not abandoned mid-flight.
• Two related reports filed from the same session, after the commit above, while the badge was already stuck: #97304, #97305 — usable as an independent timestamp anchor for "how long the badge has been wrong by this point."
• Fresh re-verification immediately before this report, via ListAgents and the session-management tool's list_sessions (linked: true, and unfiltered across the account's 40 most recent sessions): zero running agents, zero running sessions anywhere, badge still reads "1 running task."