[DOCS] [Cowork] "Not logged in · Please run /login" error reference omits the v2.1.203+ Cowork VM-mode local-agent regression that v2.1.205 fixed

Documentation Type

Incorrect/outdated documentation

Documentation Location

https://code.claude.com/docs/en/errors#not-logged-in

Section/Topic

The "Not logged in" entry under "## Authentication errors" in errors.md (the row in the "Find your error" table on line 37 also points to the same section). The matching authentication.md login-expiry subsection that ties Claude Code's login lifetime to background sessions and Cowork sessions, and the "Sessions from Dispatch" section of desktop.md that describes Cowork Dispatch spawning Code sessions, both need a brief note about how the parent's credentials are inherited.

Current Documentation

From errors.md lines 340-355, the "Not logged in" troubleshooting entry:

### Not logged in No valid credential is available for this session. ``text theme={null} Not logged in · Please run /login ` **What to do:** * Run /login to authenticate with your Claude subscription or Console account * If you expected an environment variable to authenticate you, confirm ANTHROPIC_API_KEY is set and exported in the shell where you launched claude * For CI or automation where interactive login is not possible, configure an [apiKeyHelper`](https://code.claude.com/docs/en/settings) script that fetches a key at startup * See Authentication precedence to understand which credential Claude Code uses when several are present If you are prompted to log in repeatedly, see Not logged in or token expired for system clock and macOS Keychain fixes.

The page-wide "Find your error" table (line 37 of the same file) maps the literal string Not logged in · Please run /login directly to this section.

The v2.1.205 changelog records:

Fixed Cowork VM-mode local-agent sessions failing to start with "Not logged in · Please run /login" on CLI 2.1.203+

authentication.md describes login expiry in lines 131-139 and never mentions Cowork VM-mode local-agent sessions, and desktop.md line 334-342 (the "Sessions from Dispatch" section) describes Dispatch spawning Code sessions from the Cowork tab without describing how credentials reach the spawned session.

What's Wrong or Missing?

A. The "Not logged in" troubleshooting entry is silent on the v2.1.203+ Cowork VM-mode regression

Before v2.1.205, Cowork sessions running in VM mode could spawn a local-agent session that surfaced Not logged in · Please run /login even though the parent Cowork session was authenticated. The error entry's "What to do" advice — Run /login to authenticate with your Claude subscription or Console account — was the wrong recovery path for this case. The user was already authenticated; the bug was in how the CLI 2.1.203+ build relayed credentials into the VM-mode local-agent child, so re-running /login did not unblock the session, and the error entry gives no hint that the cause is a known regression rather than a missing credential. After v2.1.205 the sessions start correctly, but the entry still does not mention this Cowork VM-mode case at all, so a user reading the entry on a v2.1.205+ build cannot tell whether their situation matches the fix or whether they actually need to re-authenticate.

B. The "Find your error" table does not route Cowork VM-mode users to a Cowork-specific recovery path

The "Find your error" table on line 37 maps the literal error message to the generic "Not logged in" section. There is no row, footnote, or inline note in errors.md indicating that this same message was a regression for Cowork VM-mode local-agent sessions in CLI 2.1.203 and CLI 2.1.204, so users searching the page for Not logged in · Please run /login have no path to a Cowork-specific explanation or upgrade hint.

C. authentication.md and desktop.md never explain how Cowork VM-mode local-agent sessions inherit authentication

authentication.md's "Renew an expiring login" subsection (lines 131-139) explicitly calls out background sessions and Remote Control as the surfaces where renewing early matters, but says nothing about Cowork VM-mode local-agent sessions — the very surface where the v2.1.203+ regression hid credentials. desktop.md's "Sessions from Dispatch" section (lines 332-344) describes how Dispatch in the Cowork tab spawns Code sessions but never documents how the parent's /login credentials reach the spawned session, which is exactly the surface where the regression presented itself. After v2.1.205, both pages should note that Cowork VM-mode local-agent sessions inherit the parent's authentication, so users have a single, accurate statement to read.

Suggested Improvement

Extend the existing "Not logged in" entry in errors.md so it covers the Cowork VM-mode local-agent case without bloating the "What to do" list:

After:

What to do: Run /login to authenticate with your Claude subscription or Console account If you expected an environment variable to authenticate you, confirm ANTHROPIC_API_KEY is set and exported in the shell where you launched claude For CI or automation where interactive login is not possible, configure an apiKeyHelper script that fetches a key at startup See Authentication precedence to understand which credential Claude Code uses when several are present {/ min-version: 2.1.205 /}If you are seeing this on a Cowork session running in VM mode (CLI 2.1.203 or 2.1.204), the message is a regression and the recovery is to upgrade to v2.1.205 or later. Cowork VM-mode local-agent sessions inherit the parent Cowork session's /login credentials; they do not require a separate sign-in. The CLI v2.1.203 build that introduced the proactive login-expiry warning stopped forwarding those credentials into the VM-mode local-agent child, which made every VM-mode local-agent session start with this error until v2.1.205 fixed the relay. If you are prompted to log in repeatedly, see Not logged in or token expired for system clock and macOS Keychain fixes.

Then add a single cross-reference sentence in authentication.md line 139 (the closing paragraph of "Renew an expiring login") that names Cowork VM-mode local-agent sessions alongside background sessions and Remote Control as a surface where renewing early matters, and a one-line note in desktop.md line 342 (the closing paragraph of "Sessions from Dispatch") that Dispatch-spawned Code sessions running in VM mode inherit the parent Cowork session's credentials.

Impact

High - Prevents users from using a feature

Additional Context

Affected Pages:

| Page | Context |
|------|---------|
| https://code.claude.com/docs/en/errors | "Not logged in" troubleshooting entry and the "Find your error" table that maps the literal message string to that section |
| https://code.claude.com/docs/en/authentication | "Renew an expiring login" subsection enumerates background sessions and Remote Control but omits Cowork VM-mode local-agent sessions |
| https://code.claude.com/docs/en/desktop | "Sessions from Dispatch" section describes Dispatch-spawned Code sessions without explaining how the parent Cowork session's credentials reach the child |

Total scope: 3 pages affected.

Version: v2.1.205 (fix); the regression was present on CLI 2.1.203 and CLI 2.1.204.

Cross-reference: The v2.1.203 login-expiry warning (the row above the regression in the same changelog) is unrelated to the credential-relay bug, even though both landed in CLI 2.1.203. The login-expiry warning is about notifying the user before the saved login expires; the Cowork VM-mode regression is about the CLI failing to forward those credentials into the VM-mode local-agent child session at startup. A user who already saw the v2.1.203 warning should not assume the same warning text is the cause of the "Not logged in" message in a Cowork VM-mode local-agent session.