[FEATURE] Let Pro and Max accounts require device verification before Remote Control attachment

[FEATURE] Let Pro and Max accounts require device verification before Remote Control attachment

Preflight

• Searched existing issues. Closest are #84862, #82095, #81550, #58270 and #74204; none covers enforcement of device verification at Remote Control attachment for individual (Pro/Max) accounts. See Related issues below for how this differs.
• Single feature request.

Summary
Remote Control lets a signed-in claude.ai web or mobile session steer a live Claude Code process on the user's machine. On Pro and Max, a valid session cookie is the only thing standing between an attacker and that capability.
Anthropic already ships the control that would fix this — Trusted Devices — and the enrollment half of it appears to reach individual accounts already. What individual accounts cannot do is require it. This request is for the enforcement toggle, not for new cryptography.

Problem
Remote Control grants a connected device the ability to steer a local Claude Code session: filesystem access, tool execution, and approval of permission prompts that are forwarded to that device. Sandboxing is off by default.
The only gate on Pro and Max is "this browser holds a valid session." There is no re-authentication at the point where capability escalates from read my conversation history to steer a process with access to my working directory.

Why account security is not a sufficient answer
Standard practice is to assume credential compromise as a starting condition and design controls that hold anyway. A model whose only control is "don't get your account taken over" fails that test.
Session tokens are the weak link precisely because they are long-lived, portable, and stealable without the password ever being exposed — infostealer malware, a malicious browser extension, an XSS bug, or a phone left unlocked on a table. "Is logged in" is a near-permanent state for most users on most devices. It establishes who opened the session at some point in the past. It says nothing about who is holding the device now.
That is tolerable when the capability behind it is reading chat history. It is not tolerable when the capability is executing tools against a working directory that may hold client code, credentials, and deployment access.

The available sign-in methods make this sharper
The login help article (13189465) documents two paths: a magic link sent by email, and Google sign-in. There is no password and no TOTP option. For magic-link accounts, the effective second factor is the email inbox — so account security reduces entirely to mailbox security, with no step-up available at any point afterward.

Precedent: platforms gate far smaller actions than this
GitHub requires re-authentication for sensitive actions within an already signed-in session — modifying an email address, authorizing a third-party application, adding an SSH key, creating a PAT. Confirmation accepts a password, passkey, security key, GitHub Mobile, or a TOTP code, after which the session enters "sudo mode" for two hours, with each sensitive action resetting the timer.
https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/sudo-mode
Note the asymmetry: adding an SSH key to a GitHub account requires fresh proof of presence. Attaching to a live Claude Code session with filesystem and tool execution on the user's machine requires none.

The control already exists
Trusted Devices (documented for Team/Enterprise, beta) requires an enrolled device credential plus a sign-in no older than 18 hours, refreshed with Face ID, Touch ID, Windows Hello, or a passkey. Checks run locally through the OS or browser; only the device public key and basic metadata are stored. Enrollment is offered only shortly after a full sign-in, so a replayed cookie cannot silently enroll a new device. The 18-hour expiry is specifically an answer to replayed credentials — a stolen token ages out.
https://code.claude.com/docs/en/remote-control#trusted-devices
Per #82095 and #84862, the enrollment mechanism already reaches individual accounts: Claude Desktop prompts to set up a passkey after login, the UI surfaces at claude.ai/settings/account#trusted-devices, and it backs Remote Control device auth. #84862 characterises it as a device-trust step layered on top of a login still completed by email, rather than a sign-in method.
So the credential exists on individual accounts. The enforcement does not: the requirement is an organization-wide setting an Owner enables, and there is no equivalent self-serve control for Pro or Max.

Proposal
Opt-in, off by default. Listed smallest-lift first; any one is an improvement.

1. New-device attachment alert. Notify the local session, and optionally push to mobile, when a device that has not previously attached connects to a Remote Control session. Detection only — no enrollment flow, no enforcement, no new credential type. This alone converts silent takeover into something the user can see.
2. Self-serve "require device verification for Remote Control" toggle. Expose the existing Trusted Devices enforcement to individual accounts as a per-account setting, reusing the credential users can already enroll. This is the primary ask.
3. Local-side pinning. A per-machine setting on the Claude Code side that refuses remote attachment from devices not previously approved from the terminal, giving users a control that does not depend on account state at all.

Documentation gap
Trusted Devices is undocumented for individual accounts. #82095 reports that as of 2026-07-28, "passkey" returned zero results on support.claude.com and the feature was absent from release notes through 2026-07-24; the login article still describes only Google and email-link sign-in. A security feature users cannot discover is a feature most users do not have. Documenting the existing enrollment path would deliver part of this request's value on its own.

Related issues

• #84862 — passkey sign-in for Claude accounts across every surface. Adjacent but distinct: that concerns the sign-in method; this concerns re-authentication at Remote Control attachment, which no sign-in method addresses.
• #82095 — Trusted Devices supports only one concurrently enrolled FIDO2 authenticator, replace-only.
• #81550 — passkey setup prompt after login crashes Claude Desktop.
• #83122 — Trusted Devices enrollment fails on Linux.
• #84582 — conflict with the VS Code "Prefer Agent Host" setting.
• #58270 — local session auth gate before Claude Code accepts prompts. Covers local invocation, not the remote attachment surface.
• #74204 — TOTP as a login method for headless/SSH environments.
• Bug report covering the verification prompt's failure to enforce on individual accounts today: https://github.com/anthropics/claude-code/issues/90265

Environment

• Platform: Windows
• Surface: Claude Code VS Code extension
• Plan: Max
• Context: freelance developer; Remote Control sessions run against client codebases.

Scope note
This request is limited to authentication at the point of remote attachment. Concerns about server-side transcript storage are a separate matter and are not in scope here.