[BUG] Remote Control daemon dies with 403 "no longer a member of the organization" while idle — Max plan personal Gmail, no client-side action

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment:

Plan: Claude Max (subscriptionType: "max", rateLimitTier: "default_claude_max_5x")
Account email: personal Gmail (NOT a business domain — the typical org-scope pattern in #28583/#34990 doesn't apply)
Claude Code version: 2.1.118
OS: Linux (remote dev VM, screen-detached claude remote-control)
Spawn cmd: claude remote-control --name debug --verbose
Token state at time of failure: not expired (expiresAt ~26h in the future), credentials file untouched, OAuth refresh path was working fine
Symptom:

A claude remote-control daemon that had been running idle for ~16 hours died autonomously with the following error sequence (timestamps in machine local time, UTC+8):

[15:09:54] Error: Poll: Access denied (403): Account is no longer
a member of the organization associated with this token..
Check your organization permissions.
[15:09:54] Shutting down 1 active session(s)…
[15:09:54] Session failed: Process exited with error cse_01PbKBwt...
[15:09:55] Failed to archive session cse_01PbKBwt...:
ArchiveSession: Failed with status 400: this API is in beta:
add managed-agents-2026-04-01 to the anthropic-beta header to use it
[15:09:56] Environment deregistered.
[15:09:56] Environment offline.
The 403 occurred at 00:09 my local PT time, while I was asleep. No client-side action: no logout, no plan change, no org switch, no claude.ai navigation. The machine had network the entire time.

A second claude remote-control --name investigate daemon spawned on the same ~/.claude/.credentials.json ~3 hours later is currently polling without errors. So the credentials themselves are valid; the failure is specific to the long-lived daemon's session-to-org binding being invalidated server-side.

Why this looks like a server-side bug, not credential / scope misconfiguration:

The same credentials work for a freshly spawned daemon → token's org claim is fine right now.
My account has no business email / org affiliations that would trip the user:sessions:claude_code scope path described in #28583, #34990. It's a vanilla personal Gmail Max plan.
Trigger correlates with idleness, not user action — strongly resembles #32982 (idle-TTL ignores keepalives).
The companion ArchiveSession 400 (beta header) error suggests internal cleanup paths still expect an old beta header (managed-agents-2026-04-01) that the binary doesn't send by default — possibly unrelated, but a second sign of version drift between server and client.
Novel data point:

I have not seen the exact wording "no longer a member of the organization associated with this token" reported on existing 403/RC issues. Issues #28583/#34990 see OAuth token does not meet scope requirement; #30102 sees Invalid OAuth token. This may be a different code path (server-side org re-validation against a stale or transiently unavailable identity service) and could help triangulate the root cause.

Reproduction: unfortunately non-deterministic — long idle period required. Logs and state retained on my machine (will share if requested).

Asks:

Confirm whether this 403 wording maps to a known server-side org check, and whether the check is meant to fire on idle daemons.
Document the expected idle TTL for claude remote-control daemons + whether keep_alive currently extends it (re: #32982).
Consider letting the client auto-reconnect on a 403/401 by re-issuing the OAuth flow and re-registering an environment, instead of Environment deregistered → process exits.

What Should Happen?

A claude remote-control daemon that has been spawned successfully
and is polling normally should not autonomously die with a 403
"no longer a member of the organization associated with this token"
error after a long idle period, particularly when:

• the user took no client-side action (no logout, plan change,

org switch, or claude.ai navigation)

• ~/.claude/.credentials.json is unmodified and not expired
• a freshly-spawned daemon on the same credentials file is

polling without errors at the same moment
Either the server should keep the env→org binding stable across
the daemon's lifetime, or the client should auto-reconnect by
re-issuing the OAuth flow + re-registering an environment instead
of logging "Environment deregistered. Environment offline." and
exiting.

Error Messages/Logs

[15:09:54] Error: Poll: Access denied (403): Account is no longer a member of the organization associated with this token.. Check your organization permissions.
[15:09:54] Shutting down 1 active session(s)…
[15:09:54] Session failed: Process exited with error cse_01PbKBwtGk3qtPYX1YBTmgSw
[15:09:55] Failed to archive session cse_01PbKBwtGk3qtPYX1YBTmgSw: ArchiveSession: Failed with status 400: this API is in beta: add `managed-agents-2026-04-01` to the `anthropic-beta` header to use it
[15:09:55] Failed to archive session session_01PbKBwtGk3qtPYX1YBTmgSw: ArchiveSession: Failed with status 400: this API is in beta: add `managed-agents-2026-04-01` to the `anthropic-beta` header to use it
[15:09:56] Environment deregistered.
[15:09:56] Environment offline.
Times above are machine-local UTC+8 (= 07:09 UTC = 00:09 PT,
i.e. while the user was asleep with no terminal session).
Daemon had been running idle for ~16h before this fired.

Steps to Reproduce

Reproduction is non-deterministic — the failure requires a long
idle period — but the setup is straightforward:

1. On a Max plan personal account (personal Gmail, no business-domain

email, not part of any Anthropic Console org), authenticate with
claude /login and confirm ~/.claude/.credentials.json contains
a valid claudeAiOauth entry.

1. In a screen / tmux / nohup wrapper, spawn a long-lived daemon:

screen -dmS rc-test bash -c 'cd ~ && claude remote-control --name test --verbose 2>&1 | tee /tmp/rc-test.log'

1. Confirm the daemon prints a pairing URL of the form

https://claude.ai/code?environment=env_<id> and reaches the
"Ready" state.

1. Do NOT interact with it — leave the daemon idle for many hours

(in my case ~16h was enough).

1. Check /tmp/rc-test.log later: the daemon will have logged the

403 + "Environment deregistered" sequence shown above, and the
process will have exited.
Note: a freshly spawned daemon on the same credentials file
immediately after the failure works fine. The failure mode is
specific to long-lived environments, not to the credentials.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

2.1.118

Claude Code Version

2.1.118

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Account / plan context:

• Plan: Claude Max (subscriptionType="max", rateLimitTier="default_claude_max_5x")
• Account email: personal Gmail (NOT a business domain — the

scope path described in #28583 / #34990 should not apply here)

• No Anthropic Console org membership; no Team workspace; never

switched workspace in claude.ai during the daemon's lifetime
Likely related to:

• #32982 (Remote Control sessions die after ~20 min idle —

server TTL ignores keepalives) ← strongest match by symptom

• #30102 (RC dies with 401 when mobile client connects, token valid)
• #28583 / #34990 (RC 403 on org-scope check, but those are

business-email accounts; mine is not)
Why this looks server-side:

1. Same credentials file works for a freshly-spawned daemon at

the same moment.

1. Failure correlates with idleness, not user action.
2. The trailing `ArchiveSession 400 (managed-agents-2026-04-01

beta header)` errors suggest internal cleanup paths still
expect a beta header the binary doesn't send by default —
may be an unrelated version-drift issue on the server side.
Novel data point: the wording "no longer a member of the
organization associated with this token" appears on no other
RC issue I could find. Other 403 issues report
"OAuth token does not meet scope requirement
user:sessions:claude_code". This may be a different code path
(server-side org re-validation against a stale identity cache?)
worth triangulating from.
Asks:

1. Is this 403 wording mapped to a known server-side org check?

Is the check supposed to fire on idle daemons?

1. What is the documented idle TTL for claude remote-control,

and does keep_alive currently extend it (per #32982)?

1. Consider client-side auto-reconnect on 403/401 instead of

"Environment deregistered → process exits".
Logs and state retained on my machine; happy to share more.