RDXS-2026-002: Remote Bridge Trust Boundary Failures in Claude Code

Background

Claude Code supports a remote bridge mode that allows a second client to connect to a running session over the network. The bridge is activated via subcommands (remote-control, rc, remote, sync, bridge) and enables remote peers to send prompts, attach files, and interact with the local session.

This audit focused on the trust boundaries between a remote peer and the local Claude Code session. The question was simple: what can a remote peer cause on the local machine before the operator approves any action?

These findings extend the attack surface documented in RDXS-2026-001 (supply-chain code execution via repo-local configuration). Where that advisory covered local/filesystem attack vectors, this advisory covers network-facing trust boundary failures in the same product.

Methodology

The same source-guided approach from RDXS-2026-001 was used. The embedded JavaScript bundle from the Claude Code 2.1.71 binary was analyzed with focus on the remote bridge subsystem: session startup sequencing, the nested-session crash guard, attachment handling, file fetch paths, and heap configuration.

Findings were confirmed through source analysis cross-referenced with runtime behavior. The nested-session bypass was verified at runtime. The attachment trust-boundary break was identified through source review with partial runtime confirmation — full exploitation was not attempted because it would require server-side state that is not visible from the client alone.

Critical Findings

1. Remote bridge entry bypasses the nested-session crash guard

Guard Bypass

In the main CLI dispatch, the remote bridge subcommands (remote-control, rc, remote, sync, bridge) are handled before the generic CLAUDECODE=1 nested-session guard. The guard explicitly states that nested sessions “will crash all active sessions.”

Runtime proof is clean: setting CLAUDECODE=1 and running a normal command hits the nested-session error, while CLAUDECODE=1 with remote-control or remote bypasses that guard entirely and reaches remote auth gating instead.

Reproduction

# Normal command — blocked by nested-session guard
CLAUDECODE=1 claude -p "test"
# Error: nested sessions will crash all active sessions

# Remote bridge — bypasses the guard
CLAUDECODE=1 claude remote-control
# Reaches remote auth gating (no crash guard)

CLAUDECODE=1 claude remote
# Same bypass — reaches remote auth

Impact

Any path that can invoke these bridge entrypoints from inside an existing Claude Code session can violate an invariant the product itself treats as crash-fatal. This means a hook, MCP server, or tool call within an active session could launch a bridge subcommand and bypass the safety guard designed to prevent session corruption.

Mitigation

The nested-session guard should be checked before the remote bridge dispatch, not after. All CLI entrypoints should pass through the crash guard uniformly.

2. Inbound remote attachments trigger local OAuth fetches and disk writes before approval

Confused Deputy

This finding was identified through source review of the bundled JavaScript extracted from the Claude Code 2.1.71 binary. The following code path was traced through minified symbols and verified against the bundle structure. Cross-user file theft could not be confirmed from the client alone because server-side UUID authorization is not visible in the client bundle.

When a remote peer sends a message with file attachments, the local bridge handler immediately:

MvA() extracts file_attachments from the inbound message
ZvA() fetches each file from /api/oauth/files/{file_uuid}/content using the local session's bearer token (responseType:"arraybuffer")
GvA() resolves the write path to join(DT(), "uploads", Qq()) and the file is written with writeFile
hvA() prepends @"path" into the prompt text
The message is injected into the session via yX({value:x, mode:"prompt", uuid:d, skipSlashCommands:!0})

All of this happens before the local operator approves any tool action. The remote peer causes local network requests (OAuth fetch with the victim's token) and local filesystem writes outside the normal tool-permission flow.

Impact

This is a confused deputy vulnerability. A remote peer can cause the local client to make authenticated API requests and write arbitrary file content to disk using the local user's credentials and filesystem access. Server-side UUID authorization was not visible from the client, so cross-user file theft could not be confirmed from the client alone — but the client is already acting outside its trust boundary.

Mitigation

File attachment fetching and disk writes should be gated behind the same tool-permission approval flow as all other filesystem operations. No remote-triggered side effects should occur before operator confirmation.

High-Severity Findings

3. Remote attachment path enables denial-of-service

Remote DoS

This finding was identified through source review and follows directly from the code path documented in Finding 2.

The same attachment handling path has no limits on attachment count or size. kvA() resolves all attachments via Promise.all(_.map(ZvA)) — every attachment is fetched as responseType:"arraybuffer", converted with Buffer.from, and held in memory simultaneously.

Additionally, remote mode force-raises the V8 heap ceiling to 8 GB via --max-old-space-size=8192 at startup. This means the process will consume memory up to 8 GB before crashing rather than hitting the normal heap limit.

Impact

A single remote message with many or large attachments can spike memory and disk usage, stall the client, or kill the session before the operator ever approves a tool action. Combined with the 8 GB heap ceiling, this can exhaust system memory on machines with limited RAM.

Mitigation

Implement attachment count and size limits. Process attachments sequentially with streaming rather than buffering all into memory with Promise.all. The 8 GB heap ceiling should be configurable or bounded by available system memory.

Non-Findings

The following were investigated and determined to be either non-exploitable or out of scope for this advisory:

The /remote slash command is a local JSX alias for session information. It refuses to run unless remote mode is already active and is not itself an attack vector.
URL-only session hijack was not confirmed. The bridge transport uses hidden session credentials (sessionUrl + ingressToken), not just the browser-visible /code/... URL.
Auth and org-policy gates do exist for remote bridge startup. This is not an unauthenticated takeover scenario.

These exclusions are documented to show the scope of the investigation and to prevent false alarm about attack paths that were considered and ruled out.

The Systemic Issue

These three findings share a common root cause: the remote bridge handler performs side effects (process spawning, network requests, file writes, memory allocation) before the local operator has approved any action.

The remote peer is treated as a trusted input source. In practice, a connected remote peer can:

Bypass the nested-session crash guard (Finding 1)
Trigger local OAuth fetches and disk writes using the victim's credentials (Finding 2)
Exhaust local memory and disk via unbounded attachments (Finding 3)

Combined with the supply-chain findings in RDXS-2026-001, an attacker with both repo access and remote bridge access has a complete kill chain: repo-local config for persistence and permission escalation, remote bridge for active exploitation.

Immediate Mitigations

The remote bridge feature does not currently have CLI flags equivalent to --setting-sources user or --strict-mcp-config that would restrict its behavior. Until these issues are addressed:

Do not enable remote bridge mode in untrusted environments or with untrusted peers.
Monitor disk usage in the uploads directory during remote sessions.
Apply the mitigations from RDXS-2026-001 (--setting-sources user, --strict-mcp-config, --permission-mode default) to reduce the combined attack surface when using remote bridge alongside local repositories.

Disclosure

We work with Anthropic and all vendors we research, and inform them before publishing. These findings were discovered during the same audit engagement that produced RDXS-2026-001 and are published as a separate advisory due to the distinct attack surface (network/remote vs. filesystem/supply-chain).

The findings affect Claude Code version 2.1.71 on macOS (arm64). Other versions and platforms were not tested.