[Bug]: Claude background subagent completion is overwritten by a late 'running' update, and Stop/cancel can't settle it #22279

Before submitting

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

Related, but with a different trigger or not covering the dismiss gap: #17099 (wake continuation runs on another provider), #18910 (stays Running after task_notification reports completed), #19993 (parent subagent hits a usage limit), #20430 (continuation gate jam).

Area

apps/server

Steps to reproduce

1. On a Claude thread running on provider instance A (claudeAgent_me), have the agent start background subagents (Agent with run_in_background).
2. While they are running, the instance hits its usage limit. Move the thread in place to another Claude instance B (claudeAgent_wrenraeconner) with t3_thread_configure, and continue the thread there. Same driver, different account.
3. Let the subagents finish.
4. Try to clear the rows that stay Running.

Expected behavior

• When their work ends, the subagents reach a terminal state, even if the parent thread has moved to another instance of the same driver.
• If T3 loses the completion anyway, there is a supported way to settle the row (Stop, dismiss, or task_cancel), without restarting the server or editing the database.

Actual behavior

Two provider-native subagents have shown Running in the Lineage panel for more than 62 hours, and their timers are still counting. Both did their work and returned on 2026-10-17. Nothing on the machine belongs to them.

orchestration_v2_projection_subagents rows (redacted):

node:provider:claudeAgent:native-item:task%3Aade21fe3f39a4fcdc | run ordinal 650 | origin provider_native | instance claudeAgent_me | status running | started 2026-10-17T18:38:25.906Z | completed_at NULL | updated_at 2026-10-20T10:38:12Z
node:provider:claudeAgent:native-item:task%3Aae896c94795fd8e2d | run ordinal 668 | origin provider_native | instance claudeAgent_me | status running | started 2026-10-17T19:56:52.782Z | completed_at NULL | updated_at 2026-10-20T10:38:09Z

Timeline (UTC, 2026-10-17):

• Runs 650 and 668 start the subagents on claudeAgent_me.
• Run 675, at 21:25, is the first on claudeAgent_wrenraeconner, after the limit move. The thread later moved again, to a third Claude instance.
• One subagent's last activity was about 19:35, before the move; the other's was about 22:17, after it.
• Both rows still read running. updated_at keeps advancing, so something touches them without settling them.

Nothing user-facing clears them:

• Stop on the thread, and settling, do nothing.
• MCP task_cancel on either id returns task_not_found: "Delegated task node:provider:claudeAgent:native-item:task%3Aade21fe3f39a4fcdc does not belong to thread 35fd672a-…". It only accepts app-owned delegated tasks.
• MCP t3_workflow_stop with the subagent id returns invalid_request: "This workflow is no longer running." So the server knows nothing is running, but the projection still says running.
• TaskStop / SendMessage from the current Claude session can't reach them, because they belonged to the earlier session and instance.

Impact

Minor bug or occasional failure

Version or commit

0.0.46-nightly.20261013.3042 (Arch t3code-nightly-bin)

Environment

Arch Linux (kernel 7.0.12), desktop app. Claude Agent SDK provider with several Claude account instances (claudeAgent_*). Parent claude-opus-5-5; subagents claude-fable-5-1 and claude-opus-5-5.

Workaround

None supported. #17099 reports that server-restart recovery (ProviderRuntimeRecoveryService) cancels such rows. A restart interrupts every other running agent, though, so it isn't usable mid-work.

Suggestion: when t3_workflow_stop or Stop finds a provider-native subagent that is "no longer running", settle its row instead of refusing. Or let task_cancel accept provider-native subagent ids.