Persistent headless `--remote-control` sessions on a server never appear in the mobile app — no safe way to reach long-running, in-progress work

Additional symptom: misleading connection-state reporting

Following up with a diagnostic detail from the iOS app. The per-session connection indicator does not reflect actual reachability, and it behaves inconsistently between the two session types:

• The interactive ccd session (Claude Code web/desktop executor) correctly shows "Remote control session is offline" / disconnected when it can't be reached.
• The headless claude --remote-control <name> sessions (spawned on a server via tmux) falsely display "connected" while being completely unresponsive — input is silently dropped, no error is surfaced.

So a dead/unreachable --remote-control fleet session is misreported as "connected", giving the user no signal that it's broken, whereas the ccd session at least surfaces an honest "offline" error. The liveness indicator for --remote-control sessions appears to reflect the last-known bridge socket state rather than live reachability.

Environment unchanged from the original report (Claude Code 2.1.206, headless Ubuntu over SSH, iOS app, same Max account). Server-side these sessions still hold established TLS connections to the bridge, yet neither appear/refresh in the fleet nor accept input.

Sharpened root cause after live-registry testing

Update after testing against the live registry (GET https://api.anthropic.com/v1/sessions, authed with the account OAuth token + x-organization-uuid + anthropic-version + anthropic-beta: ccr-byoc-2025-07-29):

1. The registry is alive — sessions from a local Mac on the same account register and show connection_status: connected right now. Not an account-wide outage.
2. Only headless server --remote-control (raw tmux) sessions fail to register — they never POST /v1/sessions, never appear in the fleet, never take input. The last such session that registered was created ~2026-07-07 19:01Z; every one spawned after is absent. Mac/SDK sessions kept registering afterward.
3. The break coincides with tengu_sessions_elevated_auth_enforcement = true (in cachedGrowthBookFeatures), alongside tengu_ccr_bridge, tengu_bridge_attestation_enforce. Looks like a session-scoped elevated-auth / device-attestation enforcement that started rejecting the headless raw---remote-control launch path.
4. Disproven local theories: a local token-optimizing proxy is a transparent pass-through for /v1/sessions (not the blocker); and replicating the working desktop auth env on a server session (CLAUDE_CODE_ENTRYPOINT=claude-desktop + CLAUDE_CODE_OAUTH_TOKEN in-env + refresh flags) still does not register — no bridge_session_create, absent from /v1/sessions.

The core question: what env / attestation must a headless, server-launched claude --remote-control <name> session provide to pass bridge_session_create and register, now that elevated-auth enforcement is on? First-party (Mac) sessions on the same account register normally; the CLI/tmux server path silently does not. A documented way for headless/CI hosts to register would fix this class of setup (VPS + tmux + remote control).

Environment: Claude Code 2.1.206, headless Ubuntu over SSH, iOS app, Max account.

This is a regression — and the affected sessions come from a public, reproducible skill

Reproducible artifact: all the affected sessions are created by this open skill (tmux + systemd + claude --remote-control <name>, with --continue auto-resume): https://github.com/chimera-defi/claude-remote-session-skill — anyone debugging can reproduce the exact launch path from it.

It is a regression, not a never-worked setup. I could previously launch these sessions with this skill and fully monitor + drive them from the iOS app. That stopped working around 2026-07-07, which lines up with tengu_sessions_elevated_auth_enforcement flipping on. Same skill, same account, same launch method:

• Before ~07-07: headless claude --remote-control sessions from this skill registered and were reachable/controllable from mobile.
• After ~07-07: the identical launch path never registers (no POST /v1/sessions), never appears in the mobile fleet, and takes no input — while my Mac-local sessions on the same account keep registering and showing connected.

So whatever attestation / elevated session-auth the new enforcement requires, the headless claude --remote-control (CLI/tmux) launch path used to satisfy (or not need) it before ~07-07 and no longer can. The ask remains: what must a headless, server-launched --remote-control session now provide to pass bridge_session_create and register? — ideally a documented path so CI/VPS/tmux setups keep working.

Precise diagnosis: the regression is tag-scoped, gated by elevated-auth enforcement

Reproduced from the account's live registry (GET /v1/sessions). Sessions carry a tags field marking launch path:

• remote-control-repl (raw-tmux claude --remote-control, the skill's launcher) — LAST REGISTERED 2026-07-07T19:01:06Z; nothing after.
• remote-control-auto (Mac desktop app) — still registering through 2026-07-11. Works.
• remote-control-sdk (SDK path) — registered after the cutoff (2026-07-10), even headless. Works.

So the break is specific to the remote-control-repl (headless CLI/tmux) tag path, on ~2026-07-07.

Confirmed the live gate: tengu_sessions_elevated_auth_enforcement = true — not attestation (tengu_bridge_attestation_enforce = false) and not version (running 2.1.206 > min 2.1.139). So the CLI/tmux --remote-control path no longer satisfies the elevated session-auth that bridge_session_create → POST /v1/sessions now requires, while the SDK and desktop paths do. (There's a trustedDeviceToken in ~/.claude/.credentials.json the raw-CLI path never presents.)

Ask: what elevated/session-scoped auth must a headless remote-control-repl session present to register now that enforcement is on — or can the mechanism the -sdk path uses be documented for CLI/tmux use? The -sdk tag proves a headless session can register post-enforcement; the raw CLI path just isn't sending whatever it sends.

Root cause found + fix (confirmed end-to-end)

Following up with the actual root cause — this is not an account/registry-side freeze; it's a client-side gate change.

A CLI update (~2026-07-07) added a first-party-base-URL requirement to the remote-control bridge-enable gate:

function xIn(){ const e = process.env.ANTHROPIC_BASE_URL; if(!e) return true; return new URL(e).host === "api.anthropic.com" }

If ANTHROPIC_BASE_URL is set to anything whose host isn't api.anthropic.com (in our case a local proxy at http://127.0.0.1:8787, set in ~/.claude/settings.json env), the bridge is silently not enabled → the session never calls bridge_session_create → never registers via POST /v1/sessions → never appears in the mobile app. Sessions with no base-URL override (e.g. the Mac desktop path) kept registering, which made the breakage look account-scoped.

This is a regression: these --remote-control sessions previously registered and were reachable/controllable from the phone; the 07-07 CLI rollout broke every session that runs behind a proxy base URL, all at once.

Repro

1. Set ANTHROPIC_BASE_URL to any non-api.anthropic.com host (e.g. a local proxy) in ~/.claude/settings.json env.
2. Launch claude --remote-control <name>.
3. Session runs fine locally but never appears in the mobile app; GET /v1/sessions shows no registration.

Workaround (validated)

Force a first-party base URL for RC launches via a dedicated --settings layer:

claude --settings /path/to/fp.json --remote-control <name>
# fp.json: { "env": { "ANTHROPIC_BASE_URL": "https://api.anthropic.com" } }

--settings merges over the user settings.json (keeps hooks/MCP/plugins) but wins the env base-URL key. Note a start-script export ANTHROPIC_BASE_URL=... does not work — user-settings env clobbers per-process env. After this, a fresh session registers with connection_status: connected and is reachable + accepts input from the phone.

Requests

• Confirm whether the first-party-base-URL gate on the RC bridge is intended. If so, this should be documented, because it silently breaks every proxied/BYOC --remote-control deployment.
• If unintended, consider allowing the bridge to enable regardless of base URL (or honoring ANTHROPIC_UNIX_SOCKET, which appears to satisfy a related gate), so proxy users keep both remote control and their proxy.

All of the affected sessions were launched with this skill: https://github.com/chimera-defi/claude-remote-session-skill