[DOCS] `agent-view.md` "background service did not respond" troubleshooting never mentions the v2.1.203 automatic recovery when the daemon's session token goes stale

Documentation Type

Incorrect/outdated documentation

Documentation Location

https://code.claude.com/docs/en/agent-view

Section/Topic

The "Troubleshooting" section, specifically the "Agent view says the background service did not respond" subsection, and the "Version history" table at the bottom of the page.

Current Documentation

The "Agent view says the background service did not respond" subsection currently reads:

If attaching, peeking, or claude logs reports that the background service did not respond, the supervisor process has likely stalled. Stop it and let the next claude agents start a fresh one. To keep your background sessions running through the restart, pass --keep-workers: ``bash theme={null} claude daemon stop --any --keep-workers ` The new supervisor reconnects to the running sessions. Without --keep-workers, the command ends the background sessions too. The --any flag confirms you want to stop a supervisor that started on demand rather than as an installed service, which is the default. A supervisor that starts but can't accept connections exits and releases its lock on its own, so the next claude agents starts a fresh one without this manual stop. The steps above apply when a running supervisor stalls. On Windows, if the supervisor doesn't respond to the stop request, the command prints its process ID. End that process with taskkill /PID <pid> to finish the recovery. Background sessions are still preserved when you passed --keep-workers`.

The page's Version history table currently lists only entries up through v2.1.202. The closest existing row, v2.1.200, mentions a different surface:

| v2.1.200 | {/ min-version: 2.1.200 /}An older Claude Code version that rewrites the session list in roster.json preserves fields written by a newer version, matching the existing state.json guarantee, so sessions started by the newer version keep accepting input after the supervisor restarts. When you open a session that has stopped responding, the supervisor restarts its process and the session continues the interrupted response from where it left off. |

What's Wrong or Missing?

A. The troubleshooting section prescribes a manual workaround that is no longer required for the daemon-session-token staleness failure mode

The v2.1.203 changelog entry states:

Fixed background sessions becoming permanently unresponsive to attach, replies, and stop when the daemon's session token went stale — the session now recovers automatically

After v2.1.203, a background session whose daemon-session-token has gone stale no longer needs the user to run claude daemon stop --any --keep-workers to recover. The session recovers on its own, and attach, replies, and stop work again without a manual daemon restart. The current troubleshooting section only describes the manual recovery path and never mentions the new automatic recovery for this specific failure mode, so a user on v2.1.203 who hits "background service did not respond" will follow outdated steps and stop a supervisor they did not need to stop.

B. The specific token-staleness failure mode is not described anywhere

The token that goes stale is the daemon's session token, not the user's stored Anthropic credentials and not the environment-variable credentials described in "Dispatch fails with Could not resolve authentication method". None of the troubleshooting entries on the page distinguish a stalled supervisor process from a supervisor whose session token has gone stale while the process is otherwise still running, so the two failure modes collapse into one entry and the new fix cannot be documented alongside the right symptom.

C. The version history has no v2.1.203 row

The "Version history" table at the bottom of agent-view.md ends at v2.1.202. There is no row summarizing the automatic recovery change, so readers cannot find it from the historical record at all.

Suggested Improvement

Option A: Add a sibling troubleshooting entry

Add a new troubleshooting entry under the existing one, scoped to the new failure mode:

### Background service did not respond, then recovers on its own If claude attach, peek, claude logs, or claude stop reports that the background service did not respond, the daemon's session token may have gone stale. {/ min-version: 2.1.203 /}As of v2.1.203 the session recovers automatically: wait a moment and retry the attach, peek, log, or stop. The session continues accepting input without restarting the supervisor. If the same command still fails after a few seconds, the supervisor itself has stalled and you need the [claude daemon stop --any --keep-workers](#agent-view-says-the-background-service-did-not-respond) recovery above.

Option B: Update the existing entry

Extend the existing "Agent view says the background service did not respond" subsection with a paragraph that calls out the v2.1.203 automatic recovery and points users at it before they reach for claude daemon stop:

{/ min-version: 2.1.203 /}If claude attach, peek, claude logs, or claude stop reports that the background service did not respond because the daemon's session token went stale, the session recovers on its own within a few seconds. Retry the command before stopping the supervisor. Stop the supervisor only when the same command still fails after retrying.

Add a corresponding row to the "Version history" table:

| v2.1.203 | {/ min-version: 2.1.203 /}A background session whose daemon-session-token has gone stale recovers automatically: claude attach, replies, claude logs, and claude stop succeed without restarting the supervisor. Earlier versions could leave the session permanently unresponsive to those commands until the supervisor was manually stopped. |

Impact

High - Prevents users from using a feature

Additional Context

Affected Pages:
| Page | Context |
|------|---------|
| https://code.claude.com/docs/en/agent-view | "Agent view says the background service did not respond" troubleshooting entry and "Version history" table |

Total scope: 1 page affected.

The claude daemon stop --any --keep-workers command documented in the CLI reference at https://code.claude.com/docs/en/cli-reference (the row for claude daemon stop --any) still has the same shape and remains valid for the stalled-supervisor failure mode. The change is only that the daemon-session-token staleness failure no longer requires it.

Mention v2.1.203 where relevant so reviewers can locate the matching changelog entry.