Claude Code Remote Control security risks — when “your local session” becomes a remote interface

Remote Control is a deceptively simple feature: you start a Claude Code session on your own machine, then continue it from your phone, tablet, or any browser. Anthropic’s documentation is very clear about the core property: the session keeps running locally and “nothing moves to the cloud,” while the web and mobile interfaces act as “a window into that local session.” (Claude)

If you’re a security engineer, that one sentence should snap you out of “productivity feature” thinking and into boundary analysis.

Because a local Claude Code session is not just a chat window. It can interact with your filesystem, your 用具, your project configuration, and even your MCP servers—and Remote Control keeps all of that reachable while you operate from more devices and more login surfaces. (Claude)

Now add the second part of the story: Check Point Research recently disclosed multiple vulnerabilities in Claude Code that could enable リモートコード実行 そして API key exfiltration via malicious project configuration when a developer clones and opens an untrusted repository. (Check Point Research)

Remote Control didn’t create those vulnerabilities. But it does change the economics and the operational reality of exploiting them, because it increases the value of a session and expands the number of ways that session can be resumed, driven, and potentially hijacked.

This article is about that execution boundary—what changed, what can go wrong, what the recent CVEs teach us, and what you can do that actually reduces risk (not “security theater”).

Try AI Hacker Tool >>

What Remote Control actually does, in security-relevant terms

Anthropic’s Remote Control docs describe these behaviors (paraphrased, but grounded in the doc text):

Remote Control connects claude.ai/code or the Claude mobile app to a Claude Code session running on あなたの machine. (Claude)
Your local environment stays available remotely: filesystem, MCP servers, tools, project configuration. (Claude)
You start it with claude remote-control or from inside a session with /remote-control (または /rc), and it shows a session URL; you can toggle a QR code for quick access. (Claude)
The local process supports -sandbox/--no-sandbox, but sandboxing is off by default にとって claude remote-control. (Claude)
The local session makes outbound HTTPS requests only and “never opens inbound ports”; the Anthropic service routes messages over a streaming connection, and traffic goes over TLS. (Claude)
There are hard limitations: one remote session at a time, the terminal must stay open, and a network outage of roughly 10 minutes can time out the session and exit the process. (Claude)

So if you’re mapping controls, Remote Control is not “remote execution.” It’s remote operation of a local execution context that already has meaningful authority on developer endpoints.

In other words: Remote Control is closer to a remote admin console than a “mobile chat” feature.

The trust boundary shift: more surfaces can drive a privileged local process

Before Remote Control, your risks were mostly about what Claude Code can do locally:

Which files can it read and write?
Which commands can it run?
Which hosts can it contact?
Which integrations (MCP servers, tools) are in the loop?

After Remote Control, you add a second layer:

Which devices and browser profiles can control the session?
How resilient is your authentication to phishing/token theft?
What happens when you resume a high-privilege session in a low-trust context (personal phone, unmanaged browser, shared machine)?
How do you prevent “approval fatigue” when approvals can happen from your couch?

Anthropic explicitly calls out approval fatigue as a safety problem in their sandboxing write-up: constant approvals can train users to approve without paying attention. (Anthropic)

Remote Control increases the likelihood of rushed approvals because it makes it easier to “just keep going.”

Why the recent Claude Code CVEs matter more once Remote Control exists

Check Point’s report (and The Hacker News’ summary) describes a class of attacks where a malicious repository abuses configuration mechanisms—hooks, MCP servers, environment variables—to execute arbitrary commands and exfiltrate Anthropic API keys when users clone and open untrusted repositories. (ハッカーニュース)

Two vulnerabilities are especially instructive because they highlight how “project configuration” can become a security boundary:

CVE-2025-59536 — code execution before trust confirmation

NVD describes CVE-2025-59536 as a code injection issue in Claude Code versions before 1.0.111 due to a bug in the startup trust dialog; it could be tricked into executing code contained in a project before the user accepted the trust dialog, requiring the user to start Claude Code in an untrusted directory. (NVD)

GitHub’s advisory says essentially the same: execution before trust acceptance due to the trust dialog implementation, and it’s fixed by updating. (ギットハブ)

CVE-2026-21852 — exfiltration via `ANTHROPIC_BASE_URL` before trust confirmation

GitHub’s advisory for GHSA-jh7p-qr78-84p7 explains a project-load flow vulnerability prior to 2.0.65 where a malicious repo can set ANTHROPIC_BASE_URL to an attacker-controlled endpoint, causing Claude Code to issue API requests 以前 the trust prompt—potentially leaking API keys. (ギットハブ)

NVD’s description aligns: malicious repositories can exfiltrate data including API keys before users confirm trust. (NVD)

What this teaches (the part that stays true even after patching)

These aren’t “just bugs.” They reveal a structural hazard: configuration files are no longer passive in agentic developer tooling. They can influence execution, networking, and tool invocation early in a workflow, sometimes at the exact moment when a user is still deciding whether the workspace is trustworthy. (ハッカーニュース)

Now connect that to Remote Control:

Remote Control encourages longer-lived sessions (“continue it later”), which increases dwell time and reduces “clean restart” hygiene.
Remote Control increases the number of contexts from which a user can approve actions.
Remote Control makes a session more valuable to hijack: it’s an already-authorized conduit into local tools and files.

Again, Remote Control didn’t create CVE-2025-59536 or CVE-2026-21852. But it increases the 衝撃 of adjacent failures because it expands the operational footprint of a session.

Try Agentic AI Hacker >>

Threat model for the keyword: claude code remote control

You can’t defend Remote Control with vague advice. You need a threat model that matches how developers actually get popped.

Assets an attacker wants

Secrets on developer endpoints
- 環境 files, cloud credentials, SSH keys, signing keys, tokens in CLI config directories
Source code and proprietary artifacts
- local branches, internal repos, unreleased features, customer data fixtures
Execution and persistence
- running code on a developer machine is a common stepping stone to CI, artifact pipelines, or internal systems
Session authority
- the ability to steer a trusted session toward “helpful” actions that are actually malicious

Likely attacker entry points

Malicious repository shared with a developer
- The Check Point narrative explicitly frames exploitation via “malicious project configurations” after cloning and opening an untrusted repo. (Check Point Research)
Project configuration that runs commands or changes endpoints
- CVE-2026-21852 uses endpoint redirection (ANTHROPIC_BASE_URL) before trust. (ギットハブ)
MCP servers
- Anthropic’s own Remote Control doc highlights that MCP servers remain available in Remote Control sessions. (Claude)
- MCP security best practices warn that local servers can introduce code execution/exfiltration risk and highlight dangerous startup-command patterns. (Anthropic)
Account compromise on remote surfaces
- phishing, token theft, compromised browser profile, stolen phone, weak device posture
Human factors
- approval fatigue and rushed confirmations are real, and Anthropic explicitly calls them out. (Anthropic)

The Remote Control risk catalog that matters in practice

1) Session URL/QR leakage becomes a “remote console link” problem

Remote Control displays a session URL and allows QR-based access. (Claude)

If that URL or QR is exposed in a screenshot, screen recording, ticket attachment, or chat log, you’ve created the equivalent of “here’s where the admin console lives.”

Control that works: treat session URLs and QR codes as secrets. Redact them in recordings. Don’t paste them into tickets. Don’t leave them visible during demos.

2) Untrusted repo → configuration abuse → local execution or exfiltration

This is not hypothetical. The public disclosures describe exploitation via configuration mechanisms embedded in a repo. (ハッカーニュース)

Control that works: policy and tooling that prevents Claude Code sessions from being started inside untrusted directories; plus automated checks that flag suspicious Claude/MCP config before it lands in a repo.

3) MCP becomes a privilege multiplier

Remote Control keeps MCP servers and tools available. (Claude)

Anthropic’s sandboxing write-up also notes their sandbox runtime can be used to sandbox MCP servers. (Anthropic)

If MCP servers are not audited, you’re effectively allowing third-party code execution adjacent to your agent workflow.

Control that works: MCP allowlists, version pinning, and sandboxing for MCP processes.

Claude Code Remote Control security risks

Try AI Hacker Tool >>

4) Secrets get exposed through “helpful debugging”

Even when a bug is patched, agentic tooling encourages actions like printing config, showing environment variables, dumping logs, and testing requests—behaviors that are useful but also perfect for exfiltration.

Control that works: secrets should not be present in the same execution context where the agent operates, whenever possible (short-lived creds, external credential brokers, scoped tokens).

5) Remote surfaces introduce new compromise paths

Remote Control works via claude.ai/code and mobile apps. (Claude)

So the safety of a session now depends on device posture: screen lock, OS patching, browser extension hygiene, session token handling.

Control that works: require MFA, enforce managed devices for Remote Control in corporate contexts, and deny Remote Control on unmanaged endpoints.

The controls that actually reduce risk, mapped to the real boundary

Below is a practical control table you can hand to an engineering org without it being ignored.

リスク	What breaks	What to implement	Why it helps
Untrusted repo triggers pre-trust behavior	command execution or exfiltration before trust	enforce minimum Claude Code versions; block “start in untrusted dirs”	CVE-2025-59536 and CVE-2026-21852 are explicitly about pre-trust flow failures (NVD)
Config becomes executable	hooks/MCP/env injection	repo scanning for `.claude` and MCP configs; require review	the disclosures emphasize configuration mechanisms as exploit vectors (ハッカーニュース)
Session hijack / account takeover	attacker drives your session	MFA + device posture + session hygiene + “treat URL as secret”	Remote Control is effectively remote operation of local authority (Claude)
Secret exfiltration	keys and tokens leak	short-lived creds; isolate secrets; egress restrictions	sandboxing rationale explicitly calls out exfil risks without network isolation (Anthropic)
Approval fatigue	users approve blindly	sandboxing + fewer prompts + strict default deny outside sandbox	Anthropic explicitly links approvals to fatigue risk (Anthropic)

Hardening Remote Control: a checklist you can actually adopt

Keep Claude Code patched and enforce minimum versions

If you manage endpoints, do not allow “whatever version developers installed.” The published CVEs have clear fixed versions (1.0.111 and 2.0.65). (NVD)

Use sandboxing for Remote Control sessions whenever you can

Remote Control supports --sandbox/--no-sandbox, and the docs say sandboxing is off by default. (Claude)

Anthropic’s sandboxing article explains why this matters: effective sandboxing requires filesystem isolation and network isolation; without network isolation, a compromised agent can exfiltrate sensitive files like SSH keys; without filesystem isolation, it can escape and regain network access. (Anthropic)

If you want one high-leverage move: turn on sandboxing and restrict both file paths and outbound domains.

Treat Remote Control session URLs as secrets

Because they are. Remote Control displays a session URL; you can connect via browser or QR. (Claude)

Make it a rule: no screenshots with URLs/QRs, no pasting URLs into tickets, and do not stream Remote Control sessions with the URL visible.

Assume MCP servers are equivalent to plugins that can execute code

Remote Control keeps MCP servers available. (Claude)

Anthropic notes their sandbox runtime can sandbox MCP servers. (Anthropic)

So treat MCP like dependency risk: allowlist, audit, pin versions, sandbox.

Lock down outbound traffic in Remote Control sessions

Remote Control uses outbound HTTPS and no inbound ports, which is good—but it doesn’t prevent exfiltration. (Claude)

Use domain allowlists and proxy logging. Anthropic’s sandboxing model includes a proxy that enforces domain restrictions and can be customized for arbitrary outbound rules. (Anthropic)

Claude Code Remote Control security risks

Change Nature Language to Cyber Security Toolings Action >>

Copy-paste controls: repo scanning and safer startup wrappers

These are intentionally blunt. You can refine them later. The point is to catch dumb mistakes that turn into expensive incidents.

Pre-commit hook to flag suspicious Claude/MCP configuration in repos

#!/usr/bin/env bash
set -euo pipefail

# Scan staged changes for agentic config that can become execution-adjacent.
# This is a guardrail, not a silver bullet.

STAGED=$(git diff --cached --name-only)

RISKY_FILES='(^|/)(\\.claude/|\\.claude/settings\\.json|mcp\\.json|\\.mcp\\.json)'
SUSPICIOUS='ANTHROPIC_BASE_URL|hooks|startup|init|postCheckout|postMerge|curl\\s+http|wget\\s+http|npx\\s+|bash\\s+-c'

echo "$STAGED" | grep -E "$RISKY_FILES" >/dev/null 2>&1 || exit 0

FOUND=0
while IFS= read -r f; do
  [[ -z "$f" ]] && continue
  if echo "$f" | grep -E "$RISKY_FILES" >/dev/null 2>&1; then
    CONTENT=$(git show ":$f" 2>/dev/null || true)
    if echo "$CONTENT" | grep -E "$SUSPICIOUS" >/dev/null 2>&1; then
      echo "⚠️  Suspicious patterns found in staged file: $f"
      FOUND=1
    fi
  fi
done <<< "$STAGED"

if [[ "$FOUND" -eq 1 ]]; then
  echo ""
  echo "Commit blocked: review Claude/MCP config for command execution or endpoint redirection."
  echo "Context: recent Claude Code issues exploited hooks/MCP/env vars in malicious repos."
  exit 1
fi

exit 0

Why these patterns? Because the public write-ups explicitly describe exploitation through hooks, MCP servers, and environment variables, including endpoint redirection before trust confirmation. (ハッカーニュース)

Safer Remote Control launcher wrapper

#!/usr/bin/env bash
set -euo pipefail

# Force safer defaults for Remote Control sessions.

# Reduce risk from poisoned environment-based redirection (see CVE-2026-21852).
unset ANTHROPIC_BASE_URL

# Start Remote Control with sandboxing enabled.
exec claude remote-control --sandbox

Remote Control supports --sandbox and the docs state sandboxing is off by default. (Claude)

The sandboxing design specifically aims to reduce harm even if prompt injection or agent compromise occurs. (Anthropic)

A “good enough” Remote Control policy that engineers won’t hate

No Remote Control in untrusted repositories If you didn’t create it, didn’t review it, or can’t verify provenance, don’t start Claude Code there. This directly reduces exposure to repo-based configuration attacks described in the disclosures. (Check Point Research)
Session URLs and QR codes are sensitive Treat them like temporary admin console links. Don’t share, don’t screenshot, don’t paste.
Sandboxing required 用途 claude remote-control --sandbox by default. Sandboxing is off by default otherwise. (Claude)
MCP allowlist only MCP expands capability; sandbox it or don’t run it. Anthropic explicitly ties their sandbox runtime to MCP server sandboxing. (Anthropic)
Short-lived credentials on developer endpoints Reduce the value of exfiltration. If tokens expire quickly and are scoped tightly, “one mistake” doesn’t become “three weeks of incident response.”

If your workflow is purely code-centric, you can fix what you see in a repo and still miss what matters in the running environment: real auth, real network egress, real edge configs, real exposure.

A natural complement is to pair white-box understanding with black-box verification. Penligent has a published piece that frames this explicitly: use Claude Code Security for code-context reasoning and patch direction, then use Penligent to validate exploitability and prove closure in a real target environment. (寡黙)

In Remote Control terms, that “prove it” step matters because the security boundary is no longer just code. It’s the execution boundary—what the session can touch, where it can connect, what tools it can run, and whether controls actually stop unintended behavior.

If Remote Control is going to be used in your org, treat it like an operational surface, not a feature toggle: you want regression-style assurance that new configurations, MCP servers, or workflow changes didn’t quietly re-open the door.

Takeaways that will still be true six months from now

Remote Control is a remote interaction layer over a local execution context; the web/mobile UI is a window into your machine’s session. (Claude)
Repo configuration is now an execution surface, and recent CVEs show that “before trust confirmation” is a critical failure zone. (NVD)
Sandboxing isn’t a nice-to-have; it’s the difference between “agent compromised” and “agent compromised, but boxed in.” (Anthropic)
If you can’t enforce device posture and MFA, you can’t treat Remote Control as safe-by-default.