[Bug]: Thread briefly shows completed (and sends a "Thread completed" notification) between orchestrator runs #24477

Before submitting

• I searched existing issues and did not find a duplicate. Related but separate: [Bug]: Parent is never notified when a delegated child's provider-initiated run ends (e.g. after a background command finishes) #21772 is about the parent not being woken when a delegated child's run ends. This report is about the client showing and announcing a completion that is immediately superseded.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web (also affects the desktop shell and mobile thread lists through shared client-runtime state)

Steps to reproduce

1. Start an orchestrating thread that delegates work to one or more subagents or background tasks.
2. Let one piece of work finish while the orchestrator still has more to do. For example, one subagent returns and the orchestrator immediately starts a continuation run to handle the result.
3. Watch the sidebar, or keep another app focused so desktop notifications are shown.

Expected behavior

The thread stays under Working until all of its work is done. You get one "Thread completed" notification, when the thread actually settles.

Actual behavior

When one run ends and the continuation run has not started yet, there is a short gap. During that gap:

1. Sidebar flicker: the thread moves from Working to the Inbox for about a second, then jumps back to Working. The Inbox also records a false "returned" timestamp, which affects Inbox ordering.
2. False completion notification: ThreadNotificationCoordinator sees latestRun.status === "completed" with a newer completedAt and immediately sends "Thread completed". Depending on settings, that can be a sound, an in-app toast or a desktop notification. The thread is not done: the next run starts a moment later. Each intermediate run that finishes can trigger another false notification, so you learn to ignore the notification.

Relevant code on main @ d53873b6a4:

• Notification trigger: apps/web/src/components/ThreadNotificationCoordinator.tsx L146–L165. The notification fires when a completed run is first observed, without waiting to see whether a follow-up run starts.
• Shelf placement uses the same instantaneous working → not-working transition.

Both symptoms come from one cause: the client treats the end of one run as the end of the thread's work, but an orchestrator continuation can start a moment later.

Impact

Minor bug or occasional failure. It happens frequently in orchestrator/subagent workflows. The flicker is cosmetic, but the false "Thread completed" notification makes completion notifications unreliable.

Version or commit

0.1.3-nightly.20261024.3617 (macOS desktop); code references are to main @ d53873b6a4.

Environment

macOS, T3 Code Nightly desktop app. Seen with orchestrator threads that delegate to subagents.

Workaround

None. You have to open the thread to check whether it is actually finished.

Related PRs

• fix(clients): hold Working placement and completion notifications through brief continuation gaps #22458 fixes the sidebar part. A thread that just stopped working stays on the Working shelf for 2 seconds. Resuming cancels the move, and the Inbox-return timestamp is only recorded once the thread really settles. Requests for approval or input, errors and manual placement changes skip the delay. That PR does not yet delay the "Thread completed" notification. The same short window could be applied to completion notifications (attention notifications would still be sent immediately), either in that PR or a follow-up. I'd like a maintainer to say which they prefer.
• fix(threads): Working holds only background work the agent waits on #22055 and fix(server): keep Claude threads working while a wakeup is pending #20318 deal with which background work should keep a thread Working at all. They do not cover the gap between one run and the next.