[Bug]: A thread whose agent leaves a dev server running stays "Monitoring" on desktop with no completion alert, while mobile reports it completed

[Vantrongs]

Before submitting

• I searched existing issues and did not find a duplicate. [Bug]: Completion sound fires when subagents or monitors finish, even though the agent resumes working #13625 is the other side of this: there the completion alert fires too early when a monitor ends and the agent resumes ("Thread completed" notification fires when a thread leaves Monitoring, before the agent resumes #13733 was closed as its duplicate). Here the desktop alert never fires.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. In a Claude thread, ask the agent to start the site on a separate port and check it.
2. The agent starts the dev server as a background shell (local_bash task), checks the page, and ends its turn with a final answer, leaving the server running for me.
3. Watch the desktop sidebar, the desktop notifications, and the mobile app.

Expected behavior

Every client tells me the same thing: the turn is done, and a server from this thread is still running.

Actual behavior

The clients disagree:

• Desktop and web sidebar: "Monitoring" for as long as the server runs, which can be hours. The in-app toast and sound "Thread completed" never fire, and the unseen "Completed" pill is hidden behind "Monitoring".
• Mobile: the thread list shows no working status, and the push notification reports the task as completed.

Impact

Minor bug or occasional failure

Version or commit

main @ de251fc (code checked); installed 0.0.43-nightly.20260926.2282

Environment

Desktop app on Linux (NixOS, Wayland, niri) and the mobile app; provider Claude (Opus 5.5)

Cause

• apps/server/src/orchestration/ThreadBackgroundLiveness.ts: local_bash and shell are in MONITOR_TASK_TYPES (packages/contracts/src/providerRuntime.ts), so a background shell that never exits keeps backgroundLiveness: "monitoring" on the thread.
• apps/web/src/components/Sidebar.logic.ts: the thread status resolves to monitoring before the unseen-completion check, so the "Completed" pill never shows.
• apps/web/src/components/ThreadNotificationCoordinator.tsx: the completion toast and sound fire only when the status becomes ready, which does not happen while the shell lives.
• packages/shared/src/agentAwareness.ts, projectThreadAwareness, and apps/mobile/src/features/threads/threadListV2.ts, resolveThreadListV2Status, look only at the session and the latest turn, not at backgroundLiveness. So mobile reports the turn as completed.

Possible fix

A compact status for the case where the turn is done and the only live background work is processes listening on ports, for example Ready · 2 servers in the desktop sidebar and the mobile list, with the ports in a tooltip or on tap (:5173, :3000), and tap to open them in the preview (openDiscoveredPort already does this on web). The completion alert fires at turn completion, as the mobile push already does. "Monitoring" stays for watch loops that will wake the agent (monitor, monitor_mcp, and shells that do not listen on a port), which keeps the fix for #13625 correct.

The data is mostly there: apps/server/src/preview/PortScanner.ts already lists listening servers with their PID, but attributes them to a thread only through T3's own terminals (registerTerminalProcesses). The agent's background shells are descendants of the provider process, so attributing listeners by the provider session's process tree would give the count per thread. On Linux the scanner depends on lsof; on my machine lsof is not installed, so it falls back to the list of common dev ports without PIDs. Reading /proc/net/tcp and /proc/<pid>/fd would avoid that dependency.

Workaround

Check the thread by hand, or ask the agent not to leave the server running.

---

Filed by Claude (Opus 5.5) in Claude Code in T3 Code, at the reporter's request; the cause was checked against the code on main (de251fc).