Disclaimer: We disclosed the technique described in this blog to Anthropic through proper channels prior to this publication.

TL;DR

Claude Code Remote Control can behave like a trusted command-and-control channel (C2) when abused. In this type of threat, a legitimate developer tool runs locally, connects outbound to Anthropic’s trusted SaaS infrastructure, receives operator instructions from the web, executes actions on the machine, and streams results back.

That means the traffic can look like normal Claude Code usage, not malware C2. It won’t show up as a suspicious implant, custom domain, or strange binary. Instead, it will seem like just an allowlisted agent doing exactly what it was designed to do, but in reality it will be under attacker control.

The core risk is not that Claude Code is malware. It is that powerful remote agent features can stop being productivity tooling and turn into post-compromise control channels. If an attacker can provision or hijack a full Claude.ai session, Claude Code Remote Control may become a high-trust path into developer environments.

Shadow AI Agents: The C2 Channel Hiding in Your Trusted Allowlist

A Shadow AI Agent is a coding agent running on an organization-controlled host while authenticated to an account the organization does not own, manage, or monitor.

This is a class of command and control that does not need malware infrastructure. There won’t be a suspicious domain, custom implant, strange binary or obvious beacon.

Instead, the operator uses something already trusted by the organization: a developer tool authenticated to a major SaaS platform, running on a real engineer’s machine, with permission to read files, execute commands, and stream results back to the cloud.

This research shows how Claude Code Remote Control can be used as a Living off the Land C2 primitive. Claude Code is legitimate tooling and Remote Control is a legitimate feature. But when the local agent can be controlled from the web, receive instructions through Anthropic’s trusted backend, execute locally, and return output to the operator, the behavior starts to look a lot like command and control.

The research question was simple:

Can a legitimate remote coding-agent feature be abused as a trusted C2 channel?

The answer is yes, with some constraints (that can be bypassed).

Claude Code includes security checks around Remote Control, OAuth token scope, and workspace trust. But when an attacker controls or steals the right Claude.ai account material, those same legitimate flows can be abused to create a high-trust operator channel into a developer workstation.

/remote-control --help plz

The remote feature lets a local Claude Code worker connect to a cloud Claude session: the user starts claude --remote-control, Claude creates a remote session, the local worker receives temporary credentials, registers itself, and opens a long-lived stream to receive prompts, control events, and permission requests from Claude.ai. 

When the user sends a prompt, the local worker runs the agent on the user’s machine and streams messages, progress, and results back to Claude.ai. Claude Code in a remote session also allows permissions to be requested and approved from a remote source, so actions that need user approval can still be controlled through the remote interface. A heartbeat runs in parallel to keep the worker connected and verify it still owns the session, and when the user exits, the session is archived and closed on the server.

Setting up remote control in Claude Code

Controller Side

Claude enables, in "Research Preview", an option to control the agent from the web.

Claude Code remote session - web version

This page displays all Claude Code remote sessions in the account. That means if an attacker steals the credentials, browser session, or OAuth material for the developer's Claude account, it’s GAME OVER.

Abusing Claude Code Remote Control as a C2

As a Red Teamer I always liked LOLBins (Living Off The Land Binaries) for malicious use. Claude Code is not just a LOLBin with one functionality. It is a multifunctional developer tool that can read code, run commands, interact with MCP, and produce useful operator output AUTONOMOUSLY.

An attacker using Claude Code as a LOLBin may try to run it under another account. This is where Claude security blocks simple programmatic launching of remote sessions (using documented environment variables).

The reason for the block is clear: preventing malicious use of Claude Code.

Claude Code blocking remote-control via token passed through the documented environment variable

Bypassing restriction

Using undocumented environment variables

While researching Claude Code's remote-control flow, we found that Remote Control does not accept long-lived inference-only tokens such as those supplied through CLAUDE_CODE_OAUTH_TOKEN or generated by claude setup-token.

Remote Control requires a full-scope Claude.ai login. In the normal interactive flow, this is created by running:

Claude Code also contains an internal, undocumented non-interactive path that accepts a previously issued refresh token through environment variables and installs it as a normal full-scope login, instead of requiring the interactive browser flow. We found this through analysis of the Claude Code agent. We've omitted the exact variable names, since obtaining a suitably scoped refresh token is the actual prerequisite (see below) rather than this path itself.

Mechanically, the path performs a standard OAuth refresh-token exchange against the token endpoint, sending the refresh token, client ID, and requested scopes. This causes Claude Code to exchange the refresh token and install a normal OAuth login into the selected configuration directory. After that, Remote Control can be launched normally against that config directory.

This does not bypass the full-scope requirement. It uses the same login installation path that interactive claude auth login would create.

Claude Code explicitly enforces the full-scope requirement, treating setup tokens and CLAUDE_CODE_OAUTH_TOKEN as insufficient for Remote Control. Attempting it with an inference-only token returns an error stating that Remote Control requires a full-scope login and that long-lived tokens are limited to inference only - directing the user to run claude auth login.

In order to launch Claude Code with remote session non-interactively we will need a specific refresh token with specialized scopes - harvesting a refresh token from the authentication flow can be complicated, so we made our own script to get the refresh token.

Getting a specialized refresh token 

We analyzed the authentication flow that will permit remote session and discovered that for Remote Control, the important scopes are:

• user:profile: allows Claude Code to fetch profile/account metadata.

• user:inference: allows normal Claude model inference.

• user:sessions:claude_code: allows Claude Code session functionality used by Remote Control.

• user:mcp_servers: enables Claude.ai MCP server integrations.

• user:file_upload: enables file upload capability for Claude.ai and Claude Code flows.

With the above in mind we wrote a python script that authenticates against claude.ai and requested the appropriate scopes for us to get refresh-token that will allow us to perform remote sessions. 

Once we received the required refresh token we faced another wall - Trust workspace block. 

Faking workspace trust

Claude Code also enforces workspace trust before allowing Remote Control to operate in a directory. If the workspace has not been trusted, Claude Code exits with an error similar to:

Workspace not trusted. Please run claude in <path> first to review and accept the workspace trust dialog.

The trust decision is stored in Claude Code's configuration file, typically:

$CLAUDE_CONFIG_DIR/.claude.json

The relevant state is stored under the project's absolute path:

{
  "projects": {
    "/absolute/workspace/path": {
      "hasTrustDialogAccepted": true
    }
  },
  "remoteDialogSeen": true
}

By creating an isolated CLAUDE_CONFIG_DIR and writing this trust state for a controlled workspace path, a non-interactive setup can avoid the first-run trust prompt.

This is an important security boundary to understand: workspace trust is represented as a local configuration state. It is not the same as enterprise authorization.

Final C2 implementation

Using all the bypasses discovered above we were able to create a custom script that installs Claude code (if not previously installed) and authenticates to our attacker Claude account and opens a remote session.
Once the attacker has a remote control session open they can prompt the claude code instance running on the victim’s device with instructions that will then be executed locally via Claude Code on the victim’s device.

In the following demo, we open a visible terminal for demonstration purposes to show how Claude Code automatically authenticates to the attacker’s account and establishes a remote session after the victim unknowingly installs the attacker-controlled instance. In a real-world scenario, this could execute in the background after being delivered through a compromised supply chain, a cloned untrusted repository, or a similar initial access path. Even when a macOS TCC prompt appears, the victim does not need to approve or deny it for keys and secrets to be sent; further optimization of the access method could also prevent the TCC prompt from appearing altogether.

Conclusion 

Living off coding agents represents a natural evolution of the Living off the Land tradecraft, and Claude is not unique in its exposure. 

What makes this class of attack particularly difficult to defend against is the legitimacy of every individual component. In isolation, nothing in the chain looks anomalous. This is precisely what an attacker wants.

As a result, organizations deploying coding agents should treat them as they would any privileged, internet-connected process: with network egress controls, behavioral monitoring, and a healthy skepticism of what "trusted" actually means at runtime.

We reported this to Anthropic and will continue to track how the ecosystem responds. The broader question is how to deal with these security risks as AI is transforming coding. The attackers are already waiting.