Trusted Devices fails open on individual accounts: revoking devices doesn't re-verify an active session, and declining "Sign in again to verify your device" has no effect either

Status Open
Reported on v2.1.247
Maintainer reply None cached
Activity 2 comments · opened Aug 28, 2026

[BUG] "Sign in again to verify your device" can be dismissed with no effect on Remote Control access

Preflight

  • Searched existing issues. #81550 (enrollment prompt crashes), #82095 (single FIDO2 enrollment) and #83122 (Linux enrollment failure) all concern Trusted Devices enrollment. #87863 shows the same "Sign in again to verify your device" modal but for the opposite defect — it fires spuriously on a dead/404 environment with healthy auth, not on a live session where declining fails to enforce. None covers the verification prompt failing to gate access on a live, attached session.
  • Single bug report.

What's wrong
Two separate enforcement points around Trusted Devices both fail open on individual accounts.

  1. Revoking all enrolled Trusted Devices does not force re-verification on a session that is already active. It keeps working, unaffected, as if nothing was revoked.
  2. Separately, claude.ai/code presents a modal reading "Sign in again to verify your device — Please sign in again to continue your session," with two options: Sign in and Not now. This modal did appear for a genuinely new, never-before-trusted device — but selecting "Not now" dismissed it and left the Remote Control session fully attached and steerable anyway. The device is not verified, the session is not downgraded to read-only, and the connection is not terminated.

Between the two, nothing in the product currently forces re-authentication at any point after initial sign-in, whether triggered by revocation or by a declined verification prompt.

Reproduction

  1. Max account, individual (no Team/Enterprise org).
  2. Remote Control session running on a Windows machine via the Claude Code VS Code extension, attached from a web browser session.
  3. At claude.ai/settings/account#trusted-devices, removed all enrolled Trusted Device credentials.
  4. The already-open web session kept working — no re-verification prompt, no interruption to Remote Control access. Revocation had no effect on the live session.
  5. Re-enrolled Trusted Device trust on that same web session.
  6. Opened a separate, never-before-trusted session in mobile Chrome on Android at claude.ai/code/session/....
  7. That new session presented the device-verification modal. Selected Not now.
  8. Sent prompts from the phone session. All succeeded, including a tool call that enumerated a directory outside the session's working directory and returned a file count.

Expected behavior

  • Revoking all Trusted Devices should force re-verification on any session currently relying on that trust, at latest on its next action.
  • When the device-verification prompt appears, declining it should deny the attachment, restrict the session to read-only, or terminate the connection.

Actual behavior
Neither control point does anything. Revocation doesn't touch the already-active web session. Declining verification on an entirely new, never-trusted device doesn't restrict it either. Full tool execution and filesystem access on the host machine continue uninterrupted regardless of which path is taken.

Impact
Remote Control grants a connected device filesystem access, tool execution, and approval of permission prompts forwarded to that device. Sandboxing is off by default.
Trusted Devices is documented as the control protecting this surface. On individual plans, both of its enforcement points — revocation and the verification prompt — fail open, which is arguably worse than having no control at all: it signals a protection that is not present. A user who revokes a device or sees a device-verification dialog reasonably concludes the surface is gated.

Environment

  • Plan: Max (individual)
  • Host: Windows, Claude Code VS Code extension, version: anthropic.claude-code@2.1.247 (VS Code extension version — claude --version unavailable, no claude CLI on PATH in this environment)
  • Remote surface: Chrome on Android
  • Date observed: 2026-08-27

Notes

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗