[FEATURE] Attach a terminal to a Remote Control session running on another machine

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Remote Control publishes a live Claude Code session so it can be viewed and steered from elsewhere. Today "elsewhere" means a browser, the mobile app, or the desktop app. It does not include a terminal.

That gap is measurable, not inferred. On Claude Code v2.1.233 (Windows):

1. Every Remote Control form in claude --help is the serving side — claude remote-control, claude --remote-control / --rc, and /remote-control inside a session. There is no flag that connects to a session someone else is serving.

1. The documentation's own "Connect from another device" section lists exactly three routes: the session URL in a browser, the QR code into the Claude app, and the session list at claude.ai/code.

1. The nearest adjacent feature is not a substitute. claude --cloud <id> attaches to a cloud session, not a Remote-Control-hosted one, and on my account it refuses before it even looks the session up:

$ claude --cloud session_01ZZZZZZZZZZZZZZZZZZZZZZZZ    # a deliberately fake id
Error: Attaching to an existing cloud session is not enabled for your account.

The id was fabricated, so the check is account-scoped and happens before session lookup — a real id takes the same path.

1. claude --teleport is a copy, not a connection. The CLI says so itself on resume: "This terminal now has its own copy of the session: new work here stays local and will not appear in the Claude app."

Proposed Solution

A client mode, in whatever spelling fits the CLI:

claude --connect <session-id | name | claude.ai/code URL>
claude remote-control --connect <session>

It would do for a terminal what claude.ai/code already does for a browser: stream the live conversation, send prompts, and surface permission prompts for approval.

A read-only viewer would already be worth shipping. If two-way steering raises the bar, streaming the session plus approving tool calls covers most of the value and is a smaller surface to secure.

Security — addressing the objection raised last time

In #37345, @HungRueiChen made a sound point: a CLI or Desktop client is not like a browser session or a phone. People do not log out of a CLI, so a long-lived credential on a shared or always-on machine would let anyone at that shell into your live sessions.

That objection has a shipped answer already: Trusted Devices, which Claude Code applies to Remote Control sessions today, requiring a device to be enrolled before it can view or steer one. Extending device enrolment to a CLI client, plus re-authentication per connection rather than per login, would make a terminal client no weaker than the mobile app.

Worth designing in from the start rather than bolting on.

Use Case

• An always-on machine or workstation runs the session with the project filesystem, MCP servers and local tools.
• A second machine connects to that session from a terminal, keeping the TUI, keyboard shortcuts and approval prompts.
• Terminal-native users get the same reach that web and mobile users already have. This complements those clients rather than replacing them.

How this differs from related issues

| Issue | What it asks for | Why this is different |
|---|---|---|
| #37345 | The same feature | Closed by the stale bot, not by a decision — see below. This re-files it with measured evidence and a security design. |
| #31992 | Session handoff | Moving a session between machines. This is simultaneous interaction with one live session. |
| #30447, #28535 | Headless mode | Removes the TTY requirement on the host. This adds a client on the connecting side. Complementary. |
| #38364 | CLI/VS Code → Chrome extension bridge | A different transport and surface; not a terminal client for Remote Control. |

On #37345 specifically: it was flagged by the duplicate detector against three issues that are not duplicates, then closed a month later by the inactivity bot with "Closing for now — inactive for too long." The author asked for a reopen, noting the closure "was auto-triggered by the stale bot, not a product decision". There was no reply, and the thread was locked seven days later. No Anthropic maintainer commented at any point, so as far as I can tell the request has never actually been evaluated.

Alternative Solutions

• SSH + tmux into the host. This genuinely works and is what the previous requester and I both fell back to — but it bypasses the Remote Control protocol entirely, needs direct SSH access to the host, and requires the session to have been started inside tmux in the first place. It is a way around the gap, not a way through it.
• A browser window beside the terminal. Works, and is what I have automated. Loses the terminal.
• claude -p "msg" --cloud <id> — one-way. You can push a prompt into a session and never see the reply.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Additional Context

The concrete setup this comes from: a dashboard that embeds real ptys and shows every local Claude session's state on a map. Sessions on a second machine can be listed and opened in a browser window, but cannot be given a terminal, because there is no client to run inside one.