Remote Control: createCodeSession returns 401 (silently) from Docker/container environments since ~2026-07-17 — attestation enforcement?

Summary

Since ~2026-07-17, Remote Control silently fails to register sessions when Claude Code runs inside a Docker container (linuxserver/code-server on a NAS). createCodeSession returns 401 Authentication failed (3 retries, then gives up with no user-visible error). The same account on macOS registers instantly. Nothing changed on the client side when it broke — evidence points to a server-side rollout, possibly tengu_bridge_attestation_enforce.

Environment

• Claude Code 2.1.212 (also reproduced on 2.1.211), native (Bun) build, linux x86_64
• Container: lscr.io/linuxserver/code-server (Ubuntu noble) on UGREEN NAS (Intel N100), sessions launched inside tmux
• Auth: claude.ai OAuth login, Pro subscription (claude auth status: loggedIn, authMethod claude.ai, firstParty)
• remoteControlAtStartup: true in settings.json
• Comparison machine: macOS, Claude Code 2.1.197, same account — /rc succeeds immediately

Symptom

Sessions start normally and inference works fine. Remote Control registration fails silently — the session never gets a bridgeSessionId in ~/.claude/sessions/<pid>.json, and never appears in the mobile/desktop Remote Control list. In-session /remote-control fails the same way.

Debug log (--debug-file):

[INFO] Bridge URL: wss://bridge.claudeusercontent.com
[DEBUG] [code-session] Session create failed 401: Authentication failed
[DEBUG] [remote-bridge] createCodeSession failed (attempt 1/3), retrying in 403ms
[DEBUG] [code-session] Session create failed 401: Authentication failed
[DEBUG] [remote-bridge] createCodeSession failed (attempt 2/3), retrying in 829ms
[DEBUG] [code-session] Session create failed 401: Authentication failed
[DEBUG] [bridge:repl] handleStateChange state=failed detail="Session creation failed — see debug log" cancelled=false outboundOnly=false

On 2.1.211 the flow additionally logs [code-session] /bridge failed 401: Authentication failed ("Remote credentials fetch failed").

Timeline (all times JST, 2026-07-17)

• 00:26 — container session registers successfully (last known good)
• 09:06 — user first notices sessions no longer appear in Remote Control (client unchanged, still 2.1.211 at that point)
• Through the day — mostly failing with occasional successes (3 of ~10 attempts succeeded midday); by evening ~0% success. Consistent with a gradual server-side rollout reaching 100%.

Ruled out (all tested)

• Fresh OAuth grant: claude auth logout + claude auth login → still 401
• Client version: 2.1.211 and 2.1.212 both fail; nothing was updated when it broke overnight
• Network/IPv6: container is IPv4-only; pinned bridge.claudeusercontent.com to its IPv4 in /etc/hosts; plain GET to the bridge host returns 426 Upgrade Required (reachable); inference traffic to the same IP works throughout
• Concurrent-session limits: reproduced with zero other registered sessions
• Stale bridge environment (#57715 workaround): registering from a different machine (macOS, success) did not unblock the container
• Anthropic status page: no relevant incident listed

Suspected cause

Both machines' cached GrowthBook features include:

tengu_bridge_attestation_enforce = true
tengu_bridge_attestation_enforce_config = { accept_level: "VERIFIED_BY_GATE", accept_statuses: [] }

macOS passes and the container does not, so it looks like bridge session creation now enforces an environment/binary attestation that headless container environments cannot satisfy, and the enforcement was enabled server-side around 2026-07-17.

Questions / requests

1. Is blocking Remote Control from container/headless environments intended? If so, please document it; many users run Claude Code on NAS/home servers precisely to use Remote Control from a phone.
2. If unintended, please accept an appropriate attestation status for environments without platform attestation (or gate by account risk instead).
3. Either way, please surface the 401 to the user — today the registration fails completely silently (no TUI message, nothing in non-debug logs), which makes this extremely hard to diagnose.