[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](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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 ` 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 ` 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

```shell

```

### 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_

Start by reproducing the named `/remote-control`, `--remote-control`, and `remoteControlAtStartup` paths with verbose logging, then compare them with `claude remote-control --name`. Trace the `/bridge` reattach request against the successful `/v1/environments/bridge` flow. Done means an existing interactive session attaches without HTTP 403, or the supported limitation and recovery path are documented.

Written by the indexing model from the issue text.