[BUG] Remote Control returns HTTP 403 on the in-session `/bridge` path, while `claude remote-control` works on the same machine and account

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?

Bug report: Remote Control returns HTTP 403 on the in-session /bridge path, while claude remote-control works on the same machine and account

Summary

On one Windows machine, every attempt to attach an existing interactive session to Remote Control fails with:

Remote Control failed to connect: Remote Control server rejected the request (HTTP 403) — run /remote-control to retry

This affects /remote-control typed inside a session, the --remote-control startup flag, and remoteControlAtStartup: true. Retrying never helps.

On the very same machine and account, the standalone command claude remote-control --name <name> connects successfully: environment registration returns 200, a session is created, heartbeats return 200, and the session is visible in the mobile app. So credentials, organization, and network are fine. The 403 is specific to the /bridge reattach path.

The problem has persisted since 2026-09-09/10 across client versions 2.1.266 (worked on 2026-09-10), 2.1.269, and 2.1.272, and is still reproducible on 2026-09-19.

Environment

| Item | Value |
|---|---|
| OS | Windows 11 Pro 10.0.26200 |
| Hostname | CHIEN_VOI |
| machine_id (from bridge debug log) | 64d7a1ba-48e6-409c-9cd7-ce748480e541 |
| organization_uuid (from bridge debug log) | e2c95ed2-9a57-4051-ab99-9bdb2d1bc827 |
| Claude Code (VS Code extension binary) | 2.1.272 (anthropic.claude-code-2.1.272-win32-x64) |
| Claude Code (CLI on PATH) | 2.1.269 |
| Auth | OAuth, valid, scope includes user:sessions:claude_code |
| Sandbox | off |

Reproduction

A. Failing path (in-session bridge)

1. Open any interactive session, for example in the VS Code extension, working directory C:\Users\admin\ToolRegIG.
2. Type /remote-control (or start with --remote-control "name", or set remoteControlAtStartup: true).
3. Result: the 403 banner above.

Debug log (--debug-file … --verbose) for this path shows:

[bridge:repl] Reattaching to persisted bridge session cse_…
[code-session] /bridge failed 403: Permission denied
/bridge 403 source=origin

source=origin indicates the origin server rejected the request, not the CDN.

B. Working path (standalone Remote Control), same machine, same minute

cd C:\Users\admin\ToolRegIG
claude remote-control --name RC-probe --debug-file rc_probe.log --verbose

Debug log excerpt (2026-09-18T17:27Z):

[bridge:init] bridgeId=c33ed313-6513-4e8d-9ae3-740aafe9ec2a dir=C:\Users\admin\ToolRegIG machine=CHIEN_VOI
[bridge:api] POST /v1/environments/bridge -> 200 environment_id=env_01XgKrGHwWaXEWS6G6cgwkgB
[bridge:init] Created initial session session_01DC4Zh8GVfBTH3fSBbLijfG
[bridge:work] Starting poll loop spawnMode=same-dir maxSessions=32
[bridge:api] GET .../work/poll -> 200 workId=cse_01DC4Zh8GVfBTH3fSBbLijfG type=session
[bridge:api] POST .../work/cse_01DC4Zh8GVfBTH3fSBbLijfG/ack -> 200
[bridge:session] CCR v2: registered worker epoch=1 attempt=1
[bridge:api] POST .../work/cse_01DC4Zh8GVfBTH3fSBbLijfG/heartbeat -> 200 lease_extended=true state=active

Zero 403s in this log. The session appeared in the Claude mobile app immediately.

C. Reattaching the existing session by ID also fails

claude remote-control --session-id e8cb1e68-b952-45e1-96dd-a2eace213258 --name ToolRegIG-VSCode

Result:

Error: Could not reach the server to look up session e8cb1e68-b952-45e1-96dd-a2eace213258. Check your network or run `claude /login`, then try again.

Network was verified working seconds earlier (path B). The session ID is the local session UUID of the VS Code extension session; it appears the lookup only knows server-issued cse_… IDs, so there is no way to expose an already-running interactive session.

What has been ruled out (measured, not assumed)

• claude doctor reports no problems. No managed settings. No API key override.
• OAuth token valid and not expired; scope includes user:sessions:claude_code; organization matches.
• Network and CDN: WebSocket handshake to wss://bridge.claudeusercontent.com returns 101; a WireGuard split-tunnel VPN made no difference when disabled.
• Client version: 2.1.269 and 2.1.272 both fail on path A; 2.1.266 succeeded on path A on 2026-09-10, so the change is server-side or account-state related, not client-side.
• Working directory: sessions started from the home directory and from project directories fail identically on path A.
• Concurrent sessions: with a single session open the 403 persists.
• Trusted devices: POST /api/auth/trusted_devices always returns "reused_existing": false, even while path B is working, so that flag is not diagnostic. Clearing Trusted devices and Active sessions on claude.ai and opening fresh sessions did not fix path A.

Impact

No interactive session on this machine can be attached to Remote Control. Only fresh sessions spawned by claude remote-control are reachable from the phone, so any context built in an interactive or VS Code session cannot be continued remotely. remoteControlAtStartup had to be disabled because every session otherwise shows the 403 banner repeatedly.

Questions

1. Why does the /bridge endpoint return 403 Permission denied for this machine and account, while POST /v1/environments/bridge on the same machine, account, and token returns 200?
2. Is there server-side per-machine or per-account state on the /bridge path (for example a stale persisted bridge session cse_… that the client keeps trying to reattach) that can be reset?
3. Is there a supported way to attach an already-running interactive session (local session UUID) to Remote Control, given that --session-id only resolves server-issued session IDs?

Debug logs for paths A, B, and C are available on request.

What Should Happen?

Bug report: Remote Control returns HTTP 403 on the in-session /bridge path, while claude remote-control works on the same machine and account

Summary

On one Windows machine, every attempt to attach an existing interactive session to Remote Control fails with:

Remote Control failed to connect: Remote Control server rejected the request (HTTP 403) — run /remote-control to retry

This affects /remote-control typed inside a session, the --remote-control startup flag, and remoteControlAtStartup: true. Retrying never helps.

On the very same machine and account, the standalone command claude remote-control --name <name> connects successfully: environment registration returns 200, a session is created, heartbeats return 200, and the session is visible in the mobile app. So credentials, organization, and network are fine. The 403 is specific to the /bridge reattach path.

The problem has persisted since 2026-09-09/10 across client versions 2.1.266 (worked on 2026-09-10), 2.1.269, and 2.1.272, and is still reproducible on 2026-09-19.

Environment

| Item | Value |
|---|---|
| OS | Windows 11 Pro 10.0.26200 |
| Hostname | CHIEN_VOI |
| machine_id (from bridge debug log) | 64d7a1ba-48e6-409c-9cd7-ce748480e541 |
| organization_uuid (from bridge debug log) | e2c95ed2-9a57-4051-ab99-9bdb2d1bc827 |
| Claude Code (VS Code extension binary) | 2.1.272 (anthropic.claude-code-2.1.272-win32-x64) |
| Claude Code (CLI on PATH) | 2.1.269 |
| Auth | OAuth, valid, scope includes user:sessions:claude_code |
| Sandbox | off |

Reproduction

A. Failing path (in-session bridge)

1. Open any interactive session, for example in the VS Code extension, working directory C:\Users\admin\ToolRegIG.
2. Type /remote-control (or start with --remote-control "name", or set remoteControlAtStartup: true).
3. Result: the 403 banner above.

Debug log (--debug-file … --verbose) for this path shows:

[bridge:repl] Reattaching to persisted bridge session cse_…
[code-session] /bridge failed 403: Permission denied
/bridge 403 source=origin

source=origin indicates the origin server rejected the request, not the CDN.

B. Working path (standalone Remote Control), same machine, same minute

cd C:\Users\admin\ToolRegIG
claude remote-control --name RC-probe --debug-file rc_probe.log --verbose

Debug log excerpt (2026-09-18T17:27Z):

[bridge:init] bridgeId=c33ed313-6513-4e8d-9ae3-740aafe9ec2a dir=C:\Users\admin\ToolRegIG machine=CHIEN_VOI
[bridge:api] POST /v1/environments/bridge -> 200 environment_id=env_01XgKrGHwWaXEWS6G6cgwkgB
[bridge:init] Created initial session session_01DC4Zh8GVfBTH3fSBbLijfG
[bridge:work] Starting poll loop spawnMode=same-dir maxSessions=32
[bridge:api] GET .../work/poll -> 200 workId=cse_01DC4Zh8GVfBTH3fSBbLijfG type=session
[bridge:api] POST .../work/cse_01DC4Zh8GVfBTH3fSBbLijfG/ack -> 200
[bridge:session] CCR v2: registered worker epoch=1 attempt=1
[bridge:api] POST .../work/cse_01DC4Zh8GVfBTH3fSBbLijfG/heartbeat -> 200 lease_extended=true state=active

Zero 403s in this log. The session appeared in the Claude mobile app immediately.

C. Reattaching the existing session by ID also fails

claude remote-control --session-id e8cb1e68-b952-45e1-96dd-a2eace213258 --name ToolRegIG-VSCode

Result:

Error: Could not reach the server to look up session e8cb1e68-b952-45e1-96dd-a2eace213258. Check your network or run `claude /login`, then try again.

Network was verified working seconds earlier (path B). The session ID is the local session UUID of the VS Code extension session; it appears the lookup only knows server-issued cse_… IDs, so there is no way to expose an already-running interactive session.

What has been ruled out (measured, not assumed)

• claude doctor reports no problems. No managed settings. No API key override.
• OAuth token valid and not expired; scope includes user:sessions:claude_code; organization matches.
• Network and CDN: WebSocket handshake to wss://bridge.claudeusercontent.com returns 101; a WireGuard split-tunnel VPN made no difference when disabled.
• Client version: 2.1.269 and 2.1.272 both fail on path A; 2.1.266 succeeded on path A on 2026-09-10, so the change is server-side or account-state related, not client-side.
• Working directory: sessions started from the home directory and from project directories fail identically on path A.
• Concurrent sessions: with a single session open the 403 persists.
• Trusted devices: POST /api/auth/trusted_devices always returns "reused_existing": false, even while path B is working, so that flag is not diagnostic. Clearing Trusted devices and Active sessions on claude.ai and opening fresh sessions did not fix path A.

Impact

No interactive session on this machine can be attached to Remote Control. Only fresh sessions spawned by claude remote-control are reachable from the phone, so any context built in an interactive or VS Code session cannot be continued remotely. remoteControlAtStartup had to be disabled because every session otherwise shows the 403 banner repeatedly.

Questions

1. Why does the /bridge endpoint return 403 Permission denied for this machine and account, while POST /v1/environments/bridge on the same machine, account, and token returns 200?
2. Is there server-side per-machine or per-account state on the /bridge path (for example a stale persisted bridge session cse_… that the client keeps trying to reattach) that can be reset?
3. Is there a supported way to attach an already-running interactive session (local session UUID) to Remote Control, given that --session-id only resolves server-issued session IDs?

Debug logs for paths A, B, and C are available on request.

Error Messages/Logs

Steps to Reproduce

Bug report: Remote Control returns HTTP 403 on the in-session /bridge path, while claude remote-control works on the same machine and account

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.276

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

2026-09-29 19:09:41 [info] Remote control enabled: "https://claude.ai/code/session_…"
2026-09-29 19:56:52 [info] Remote control enabled: "https://claude.ai/code/session_…"
2026-09-29 19:56:52 [info] [remote-control] bridge_state: "connected"
2026-09-29 20:46:03 [info] [updater] Checking for updates
2026-09-29 20:50:05 [info] beforeQuit: handler fired, going down
2026-09-29 20:50:59 [info] Starting app {
2026-09-29 20:50:59 [info] [CCD] Initialized with version 2.1.284
2026-09-29 20:57:31 [error] Failed to toggle remote control for local_…: "Remote Control initialization failed"

2026-09-29 20:51:01.752 [info] state pending → pending trigger=launch intent=default served=2 registering=0 failed=0 excluded=0 limited=0 missing=1 sessions=0
2026-09-29 20:51:02.114 [info] state pending → off trigger=gate intent=default served=2 registering=0 failed=0 excluded=0 limited=0 missing=1 sessions=0

2026-10-02 13:29:55 [info] Enabling remote control for session local_…
2026-10-02 13:29:55 [error] Failed to toggle remote control for local_…: "Remote Control initialization failed"

[bridge:repl]   Reattaching to persisted bridge session cse_<OLD> at seq 24712
[remote-bridge] Reattaching to session cse_<OLD>
[remote-bridge] Unarchive session_<OLD> status=200
[code-session]  /bridge failed 403: Permission denied
[remote-bridge] fetchRemoteCredentials failed (attempt 1/3), retrying in 405ms
[code-session]  /bridge failed 403: Permission denied
[remote-bridge] fetchRemoteCredentials failed (attempt 2/3), retrying in 1124ms
[code-session]  /bridge failed 403: Permission denied
[remote-bridge] Reattach to cse_<OLD> failed; falling back to fresh session
[remote-bridge] Created session cse_<NEW>
[remote-bridge] Fetched bridge credentials (expires_in=46800s)
[remote-bridge] v2 transport connected
[bridge:repl]   handleStateChange state=connected