[BUG] Forking a `claude remote-control` session from Claude Desktop fails: 403 "elevated session requires a trusted device"

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (related but different: #84436 — Fork option missing for claude remote-control sessions; #95339 / #78563 — forks not connected to Remote Control)
• [x] This is a single bug report
• [ ] I am using the latest version of Claude Code — 2.1.288; 2.1.289 came out today and its changelog has no Remote Control / fork / trusted-device changes

What's Wrong?

On a headless Linux host running claude remote-control (server mode, default same-dir spawn), I open one of its sessions in the Claude Desktop app and press Fork. The app shows "Couldn't fork this session." every time, and no fork session is created.

With claude remote-control --debug-file … the fork_conversation control request reaches the spawned session, passes the early checks, and then session creation fails: the API returns 403 elevated session requires a trusted device. The control response is {"forked":false,"error":"fork failed","reason":"fork_failed"}, about 0.7 s after the request.

The request itself comes from a trusted device (the incoming control_request is logged with attestation=DEVICE_ATTESTATION_STATUS_VERIFIED), and the host's ~/.claude/.credentials.json does contain a trustedDeviceToken key. So either the fork path doesn't present the host's trusted-device token when it creates the session, or the server doesn't accept it for this call.

The same UI error happened on 2.1.281, before I restarted the server on 2.1.288 (no debug log was captured then).

What Should Happen?

The fork should be created as a background session on the host, as the 2.1.273 changelog describes ("Added forking a session started with claude --remote-control or /remote-control from the Claude app; the fork runs as a background session on your computer").

If the host first has to be enrolled as a trusted device, the app should say so and explain how, instead of showing a generic "Couldn't fork this session."

Error Messages/Logs

# server log (--debug-file), [bridge:ws]
2026-10-04T16:03:34.994Z {"request":{"subtype":"fork_conversation","title":"<title> (fork)"},"request_id":"fork_conversation-1791129817610-ctok4s","type":"control_request"}
2026-10-04T16:03:35.686Z {"type":"control_response","response":{"subtype":"success","request_id":"fork_conversation-1791129817610-ctok4s","response":{"forked":false,"error":"fork failed","reason":"fork_failed"}}}

# spawned session's debug log
2026-10-04T16:03:34.993Z [DEBUG] SSETransport: Event seq=207 ... event_type=control_request payload_type=control_request attestation=DEVICE_ATTESTATION_STATUS_VERIFIED
2026-10-04T16:03:35.685Z [DEBUG] [bridge] Session creation failed with status 403: elevated session requires a trusted device

Possibly related: from inside the same session, reading that session's own events through the remote sessions API is refused with elevated_session_untrusted_device. That also suggests the host isn't treated as a trusted device.

Steps to Reproduce

1. On a Linux machine, sign in with a claude.ai account (Pro) and run claude remote-control in a trusted folder (defaults).
2. In Claude Desktop, open a session in that environment, send a message, and wait for the turn to finish.
3. Press Fork under the last message.
4. "Couldn't fork this session." appears, and no fork session is created.
5. To see the log lines above, restart with claude remote-control --debug-file /path/rc.log and repeat.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.288 (Claude Code), on the host running claude remote-control

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux (Debian 13 in an LXC container, headless). Client: Claude Desktop on Windows.

Terminal/Shell

Other (tmux over SSH)

Additional Information

• Spawned sessions run with permission mode auto.
• The server is a long-running claude remote-control that shows "Environment preserved" on SIGINT. After a restart it reattaches its sessions, and fork fails the same way before and after.