Claude Code Remote Control: resume your WSL sessions from your phone

The problem: Claude Code in WSL, but I want to work from the couch

I've been living in WSL2 under Windows for almost a year now. My Claude Code sessions pile up in ~/.claude/projects/-home-kwuic-projects-*, history JSONLs getting longer, todos lingering around, sometimes hours of context per session.

What annoyed me: the moment I leave my desk, nothing. The Claude app on my iPhone shows my claude.ai conversations fine, sure, but it completely ignores what's running on the WSL side. I tested the obvious first (because hope dies last): no, Claude Desktop cannot open WSL sessions. The claude --resume <session-id> CLI doesn't work from another filesystem either. Each environment (native Windows, WSL, Desktop app) is locked in its own bubble.

I cobbled together three workarounds before giving up. Tailscale + SSH + Termius from the iPhone: works, but typing code on a mobile keyboard in a bare terminal, honestly, no thanks. GitHub Actions for delegating tasks: asynchronous, so you ask a question in the morning and read the answer waiting for the train. Zero natural workflow.

Until Anthropic shipped Remote Control in spring 2026.

The solution: claude remote-control

Starting with Claude Code 2.1.51, a subcommand does exactly what we want:

claude remote-control

What it actually does. The binary opens a bridge between your local terminal and Anthropic's servers. It displays a QR code and a claude.ai/code?environment=env_xxxxx URL. You scan with the Claude app (Code tab) or open the URL anywhere. From there, the session keeps running on your machine (files, MCP, git, WSL env intact) and mobile + desktop stay synced in real time.

It's the opposite of a cloud editor like Cursor Web. Compute stays local, only the UI is remote. Your MCP secrets, credentials, private code never leave the machine. For anyone with a .env.claude packed with sensitive API keys, that changes everything.

The trap that cost me 30 minutes

First launch, full of hope:

❯ claude remote-control
Error: Remote Control is not yet enabled for your account.

On a $200/month Max plan. Excuse me?

First reflex: dig into /config, claude.ai/settings, claude.ai/admin-settings. Wasted a solid half hour hunting a toggle that doesn't exist. The feature is gated server-side via GrowthBook, Anthropic's feature flag system. More specifically by an internal flag named tengu_ccr_bridge (don't ask me where the name comes from).

Digging into GitHub issues (#34528, #29569) and a community minified-binary analysis, you land on the real cause.

The guilty code

Somewhere in the claude binary, a function Pv() decides whether the client should query the feature flag service:

// Reconstructed from minified code
function Pv() {
  return !!process.env.DISABLE_TELEMETRY || !!process.env.CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC
}

function qA(flagName, defaultValue) {
  if (!Pv()) {
    return fetchFromGrowthBook(flagName, defaultValue)
  }
  return defaultValue // ← always returns false for gated features
}

// Later:
const remoteControlEnabled = qA('tengu_ccr_bridge', false)

Concretely: if DISABLE_TELEMETRY=1 is set (or its alias CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC), the client never even asks the server. It assumes all gated features are false. Remote Control disappears, the error message drops. No warning.

What bothers me about this design

This function conflates two things that have nothing to do with each other:

• "I don't want to send analytics" (perfectly legitimate privacy preference)
• "I'm a client that physically can't reach Anthropic" (Bedrock, Vertex, Foundry cases)

When I disable telemetry, I want to cut the upload of analytics. Not cut the read of flags that decide what my $200 Max subscription is allowed to do. Two endpoints, two use cases, two different design questions. Here they end up gated by the same boolean. That's pretty much nonsense.

A few PRs are pushing to split this on Anthropic's side. Meanwhile, it's on us to know the trap.

What's safe vs what breaks

I had four opt-out variables in my settings.json:

{
  "env": {
    "DISABLE_TELEMETRY": "1",
    "DISABLE_ERROR_REPORTING": "1",
    "DISABLE_NON_ESSENTIAL_MODEL_CALLS": "1",
    "CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY": "1"
  }
}

Verdict after reading the code:

Classic trap: DISABLE_NON_ESSENTIAL_MODEL_CALLS looks visually similar to CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC (one underscore and three letters apart). But they're two different variables with two different effects. It's DISABLE_TELEMETRY that breaks Remote Control, not the other one. I almost deleted the wrong one.

The fix that actually works

OK, here's what finally unblocked me:

1. Remove DISABLE_TELEMETRY (and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC if you have it) from ~/.claude/settings.json:

{
  "env": {
    "DISABLE_ERROR_REPORTING": "1",
    "DISABLE_NON_ESSENTIAL_MODEL_CALLS": "1",
    "CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY": "1"
  }
}

2. Check it's not in the shell either:

grep -i -E "DISABLE_TELEMETRY|NONESSENTIAL_TRAFFIC" ~/.bashrc ~/.zshrc ~/.profile ~/.config/fish/config.fish 2>/dev/null

3. Close the terminal completely. The variable is still exported in the parent shell env, so just rerunning claude in the same window won't cut it. And if you're in an IDE-integrated terminal (VS Code, Cursor), kill all instances to flush the inherited env.

4. Refresh the client-side feature flag cache by re-authenticating:

claude
# inside the session:
/logout
/login   # OAuth claude.ai, definitely NOT API key

5. Test:

claude remote-control

If all good:

Take this session with you and pick up right where you left off on any device.
Open the Code tab in the Claude mobile app, or visit claude.ai/code in a browser.

Enable Remote Control? (y/n)

Spawn mode choice: same-dir or worktree

First launch, Claude Code asks you a question:

Spawn mode for this project:
  [1] same-dir — sessions share the current directory (default)
  [2] worktree — each session gets an isolated git worktree

My take:

• same-dir: all sessions launched from mobile work in the current directory. Simple. But if you spawn 2 sessions in parallel, they might step on each other editing the same files.
• worktree: each session gets its own isolated git worktree on a dedicated branch. Safe parallelism, with the overhead that comes with it (worktrees to clean up, branches to merge afterward).

For this blog where I write sequentially, same-dir is plenty. For a codebase where you want to let mobile work on tickets while you handle something else at the desk, worktree becomes worth it. You can switch mid-flight with the w key, or restart with --spawn=worktree.

Detached workflow: tmux so you don't block a terminal

By default, claude remote-control ties up your terminal in the foreground. Close Windows Terminal and the session dies. Since I close Windows Terminal roughly every hour (bad habit), I needed a solution. tmux, obviously.

# Create a tmux session named "rc"
tmux new -s rc

# Inside tmux: launch the remote
claude remote-control

# Detach (Ctrl+B then D): terminal closes, remote keeps running
# Come back later:
tmux attach -t rc

With that, the remote lives in the background as long as the machine is on. I can close Windows Terminal, open Steam, do whatever. The phone stays connected. The day I want to come back via CLI, tmux attach -t rc and that's it.

Three aliases in ~/.bashrc to avoid retyping:

alias rc-start='tmux new -d -s rc "claude remote-control"'
alias rc-attach='tmux attach -t rc'
alias rc-stop='tmux kill-session -t rc'

What works, what doesn't (yet)

Works:

• Resuming any session launched via remote on mobile or desktop
• Live file editing (changes appear on both screens)
• Running bash commands, reading logs
• Local MCP servers available (Trello, Tavily, etc., all the ones configured locally)
• Push notifications when a long-running task finishes

Doesn't work (or not yet):

• Resuming a session launched before going remote. The old JSONLs in ~/.claude/projects/ stay invisible from mobile. Only what you launch via remote-control is accessible.
• Working without internet (obviously, it's a cloud bridge).
• Keeping the session if the machine shuts down or if WSL2 gets paused by Windows (the claude process must stay alive).

On that last point, it's sneaky: Windows 11 aggressively pauses WSL2 after a few minutes of inactivity. You think your session is running, when in reality your Linux VM is frozen. Fix: create %UserProfile%\.wslconfig with:

[wsl2]
vmIdleTimeout=-1

To fully disable the idle timeout. Took me 3 days to figure out why my sessions kept dropping when I left my laptop alone a bit too long.

Wrapping up

Remote Control really unblocked me for working from the couch or on the train. One command, a QR code, and the phone becomes a clean Claude Code client. No SSH workaround, no Tailscale, no gas factory. Most importantly, code stays on the machine.

The DISABLE_TELEMETRY trap, that's a lesson I'm keeping: on Claude Code, the moment a paid feature stops working, check your opt-out variables before blaming Anthropic. If you want the bare minimum privacy without breaking anything, DISABLE_ERROR_REPORTING + DISABLE_NON_ESSENTIAL_MODEL_CALLS + CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY cover 95% of the need without touching GrowthBook flags.

I hope Anthropic eventually decouples analytics from flag fetching. It's not the end of the world, but it's the kind of gotcha that costs people half an hour. Like me.