[Bug] Working loader timer resets to 0 when you reattach to a background session

[stanleytejakusuma]

Summary

The working loader shows "Waiting 0s" when you reattach to a session that has been streaming in the background with no client attached. The elapsed counter restarts from zero on every reattach, session switch, or return from the agents view, even though the agent has been working for minutes. Background execution itself is unaffected; the timer is display only.

Environment

• Prime Agent 0.7.3, installed via Homebrew (npm package)
• macOS 26.6.2 on Apple Silicon (arm64)
• Node.js v26.5.1
• Default background daemon, daemon attached TUI

Symptoms

1. Start a long task in a session, then detach or switch to another session. The agent keeps working with zero attached clients.
2. Reattach to that session, or return from the agents view. The status bar loader reads "Waiting 0s" (or "Writing 0s") and counts up from zero, even when the agent has been streaming for several minutes.
3. Switch away and back again. The counter resets to zero once more.

The timer never reflects the actual time the current turn has been running, and it does not survive a client detach and reattach.

Suspected trigger

The elapsed time is computed entirely on the client side. The loader renders Date.now() - workingStartedAt, and workingStartedAt is stamped in exactly one place, startWorkingLoader(), at the moment the current client process starts or restarts the loader.

The loader restarts on every agent_start event, on session switch (renderCurrentSessionState calls syncWorkingLoader), on reattach (rebindCurrentSession calls syncWorkingLoader), on return from the agents view, and after streams, compactions, and retries complete.

The daemon never sends an activity start timestamp. The session list exposes only activity: { kind: "writing" | "waiting" } in daemon-session-list.js, and the attach result carries isStreaming plus a snapshot. No started-at field exists on the wire, so the client has nothing to continue the timer from and must start over.

Evidence that background execution continues

I watched five fully detached sessions (zero attached clients each) for 75 seconds. Message counts advanced by 5 to 12 per session, JSONL events kept landing seconds before each check, and no session was stuck in streaming state. isStreaming is worker-side state and tracked reality the whole time.

Expected behavior

The timer should show how long the current turn has been running and keep that time across detach and reattach.

Suggested fix

The daemon should send an activity start timestamp, the moment the current agent turn began, for example activity.startedAt, in both the session list and the attach snapshot. The client should render elapsed time from it when present and fall back to the local clock only when it is absent.

Related reports

Searched existing discussions for timer, waiting, reattach, and background reports. No matching report found. Closest are #1405 (quota error masked as Waiting) and #1461 (background subprocess console flash on Windows), both different issues.

Files

• packages/coding-agent/src/modes/daemon/daemon-session-list.js
• packages/coding-agent/src/modes/daemon/daemon-mode.js
• packages/coding-agent/src/modes/interactive/interactive-mode.js

[stanleytejakusuma]

Additional symptom: token counters reset too

The token counters in the loader reset with the timer, same root cause.

resetCurrentSessionRenderState() calls activityTracker.reset() and sets contextUsageTokenBaseline = 0 on every session switch and reattach (interactive-mode.js). AgentActivityTracker.reset() zeroes completedTokens, streamingUsageTokens, streamingChars, runningToolCount, and reportedTokens.

So the loader shows the token count for the current turn from zero every time you reattach, instead of the actual in/out tokens the turn has consumed. Like the elapsed timer, this is client-local state with no daemon-provided baseline to continue from.

The fix should cover both: a daemon-provided activity start timestamp and token baseline (for example activity.startedAt plus the turn's accumulated usage at attach time), with the client rendering from those when present.

[stanleytejakusuma]

Can implement this

I have the full path mapped and can implement the fix if the approach fits your roadmap.

Change set:

1. Daemon side. Add an activity start timestamp to the session list and attach snapshot. The natural spot is the moment the current agent turn began, exposed as activity.startedAt in daemon-session-list.js, and the same field carried in the attach result from daemon-mode.js. Optionally include the turn's accumulated usage tokens at attach time so the token counter has a baseline too.
2. Client side. In interactive-mode.js, render elapsed time from activity.startedAt when present in getWorkingLoaderMessage(), falling back to the local workingStartedAt clock only when the field is absent. Same for the token counters, using the attach-time baseline.

Why this shape: it keeps the change additive. Older daemons without the field keep the current client-local behavior; newer ones get a timer and token count that survive detach and reattach. No breaking change to the wire format.

I understand PRs are limited to vouched contributors per CONTRIBUTING.md, so I am not opening one unprompted. If this is wanted, I can prepare the patch and validate it against the daemon protocol tests. If the maintainers already have this on the v0.8 stack, just say so and I will drop it.

[snimu]

Addressed by #1605