Error messages

Remote Control failed

Remote Control failed

Remote Control is the Claude Code feature that lets you drive a session on your own computer from claude.ai/code or the Claude app on a phone. The code still runs on your machine; the phone is a window onto it. To set that up, Claude Code registers the session with Anthropic's servers over ordinary outbound HTTPS, and when that registration doesn't work you get this:

Remote Control failed

205 issues in the anthropics/claude-code repo quote that line as of September 25, 2026. We read the 2.1.282 binary, Anthropic's Remote Control docs and a stack of those issues to work out where it comes from.

The line is two parts, and the second is the useful one

In the terminal the notification is assembled from a template: "Remote Control", then "failed" if the session never connected or "disconnected" if it had, then a middle dot and a reason. The small status indicator changes to /rc failed at the same time. So a bare "Remote Control failed" in a screenshot is missing the half that says what went wrong.

The Claude desktop app wraps it differently, and this surprised me. The string "Remote Control failed to connect:" isn't in the CLI binary at all. The desktop app adds it, which is why so many reports read like this:

Remote Control failed to connect: Remote Control initialization failed

“Remote Control initialization failed” is the no-reason reason

This one's the least informative of the lot. In the code it's a fallback: setup came back without a session, and nothing earlier had recorded a more specific cause, so this generic text fills the gap. It tells you it didn't work and nothing more.

The reports lean heavily toward the desktop app. One user on desktop 1.40609.1 (bundling CLI 2.1.255) wrote in #91325 that /remote-control inside the app "fails every time" while the identical command from a terminal "works" on the same account. If you're stuck on this in the desktop app, starting the session from a terminal with claude --remote-control is worth a try before anything else, since that's the path the reporter found working.

Otherwise run claude doctor. Anthropic's docs point there, and the 2.1.282 doctor carries a line per eligibility check (signed in to claude.ai, the org policy, whether you're on the Anthropic API), which turns a vague failure into a named one.

What “server rejected the request (HTTP 403)” means

Remote Control failed to connect: Remote Control server rejected the request (HTTP 403)

Claude Code sorts 403s by who sent them. When it can tell the refusal came from something between you and Anthropic, it says so in different words: either "a network edge refused the connection before it reached Anthropic's server", which the code notes "often follows a VPN or network change", or a refusal that's "usually a proxy, VPN or firewall on this network". The plain "server rejected the request" wording is what's left when it didn't classify the 403 that way.

Why Anthropic's own server would refuse a signed-in account isn't something I could establish. No staff reply on the issues I read explains it, and several (like #95619) report desktop sessions always getting 403 while CLI sessions connect. On a session that was already connected, the docs say Claude Code keeps retrying 403s for up to three minutes before it gives up.

Settings that switch Remote Control off without saying much

Most of the named reasons come from requirements in Anthropic's docs, and a few are easy to trip over:

• It needs a claude.ai login on Pro, Max, Team or Enterprise. API keys aren't supported, and an ANTHROPIC_API_KEY in your environment takes precedence over the login.
• A token from claude setup-token or CLAUDE_CODE_OAUTH_TOKEN can only make model requests, so it can't start Remote Control.
• Bedrock, Google Cloud, Foundry, or ANTHROPIC_BASE_URL pointed at a gateway all block it.
• DISABLE_TELEMETRY, DO_NOT_TRACK, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC and DISABLE_GROWTHBOOK each turn off the feature-flag check Remote Control depends on.

That last one catches privacy-minded setups (it's easy to set DO_NOT_TRACK once in a dotfile and forget it). On Team and Enterprise, Remote Control is also off until an Owner turns on its toggle in the Claude Code admin settings.

The other reasons you might see after the dot

Remote credentials fetch failed means Claude Code couldn't get the short-lived credential the connection runs on. The docs suggest claude remote-control --verbose to see the underlying error, and name a firewall or proxy blocking port 443 as a common cause. Remote Control got an unexpected server response means your version can't read what the server sent back, and retrying on the same version fails the same way, so run claude update first.

Anything that says "login expired", "OAuth token" or "run /login" is a sign-in problem rather than a connection one: run /login, then /remote-control. Our page on the expired OAuth token message covers the sign-in side in more depth. And if you resumed an old conversation and got "Couldn't reconnect to your Remote Control session", your local session is fine; run /remote-control to retry or start fresh with claude --remote-control.