[BUG] `claude rc` / `claude remote-control` crashes with `node: bad option: --sdk-url`

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Running claude rc or claude remote-control immediately crashes after session creation with:

node: bad option: --sdk-url

The CLI spawns a child process using --print as an argument, but Node.js interprets --print as its own flag (equivalent to node -p), consumes it, and then fails when it encounters --sdk-url as the next argument — which is not a valid Node flag.

From the minified source, the subprocess is spawned with arguments like:

["--print", "--sdk-url", <url>, "--session-id", <id>, "--input-format", "stream-json", "--output-format", "stream-json"]

Node eats --print and then chokes on --sdk-url.

What Should Happen?

claude rc should start a Remote Control session and provide a connection URL for claude.ai/code access.

Error Messages/Logs

$ claude rc

[22:32:51] Session failed: /home/kowalski/.nvm/versions/node/v22.22.0/bin/node: bad option: --sdk-url session_01VbtbVLC5XQ8XAJebo9MfzH
[22:32:51] To reconnect: claude --resume session_01VbtbVLC5XQ8XAJebo9MfzH

Steps to Reproduce

1. Run claude rc or claude remote-control from a trusted workspace
2. Session is created but immediately fails with the bad option: --sdk-url error
3. Tested with Node v22.22.0 (LTS) and Node v24.12.0 — same result on both

Claude Model

Claude Opus 4.6 (Claude Max subscription)

Is this a regression?

Unknown — first time attempting Remote Control.

Claude Code Version

2.1.55 (Claude Code)

Platform

Claude Max (not API)

Operating System

Linux (CloudLinux/RHEL 8, kernel 4.18.0-553.76.1)

Terminal/Shell

bash

Additional Information

• Tested on both Node v22.22.0 (LTS) and Node v24.12.0 — identical failure
• Regular claude, claude --resume, and claude --dangerously-skip-permissions all work fine
• Only claude rc / claude remote-control is affected
• The root cause appears to be the --print argument in the subprocess spawn args colliding with Node's built-in --print / -p flag