Claude Code Remote Control : reprendre ses sessions WSL depuis le téléphone

Le problème : Claude Code en WSL, mais je veux bosser depuis mon canapé

Ça fait bientôt un an que je vis dans WSL2 sous Windows pour bosser. Mes sessions Claude Code s'empilent dans ~/.claude/projects/-home-kwuic-projects-*, des JSONL d'historique qui s'allongent, des todos qui traînent, parfois plusieurs heures de contexte par session.

Le truc qui m'énervait : dès que je m'éloigne du bureau, plus rien. L'app Claude sur iPhone affiche bien mes conversations claude.ai, OK, mais elle ignore totalement ce qui tourne côté WSL. J'ai d'abord testé l'évidence (parce qu'on espère toujours) : non, Claude Desktop ne peut pas ouvrir les sessions WSL. La CLI claude --resume <session-id> non plus depuis un autre filesystem. Chaque environnement (Windows natif, WSL, app Desktop) est enfermé dans sa bulle.

J'ai bricolé trois solutions avant de laisser tomber. Tailscale + SSH + Termius depuis l'iPhone : ça marche, mais taper du code sur clavier mobile dans un terminal nu, franchement, non merci. GitHub Actions pour déléguer des tâches : asynchrone, donc tu poses une question le matin et tu lis la réponse en attendant le RER. Aucun workflow naturel.

Jusqu'à ce qu'Anthropic shippe Remote Control au printemps 2026.

La solution : claude remote-control

Depuis Claude Code 2.1.51, une sous-commande fait exactement ce qu'on attend :

claude remote-control

Ce que ça fait concrètement. Le binaire ouvre un bridge entre ton terminal local et les serveurs Anthropic. Il t'affiche un QR code et une URL claude.ai/code?environment=env_xxxxx. Tu scannes avec l'app Claude (onglet "Code") ou tu ouvres l'URL n'importe où. À partir de là, la session continue de tourner sur ta machine (fichiers, MCP, git, env WSL intacts) et mobile + desktop sont synchronisés temps réel.

C'est l'inverse d'un éditeur cloud genre Cursor Web. Le calcul reste local, seule l'UI est distante. Tes secrets MCP, tes credentials, ton code privé ne quittent jamais la machine. Pour quelqu'un qui a un .env.claude blindé d'API keys sensibles, ça change tout.

Le piège qui m'a fait perdre 30 minutes

Premier lancement, plein d'espoir :

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

Sur plan Max 200$/mois. Pardon ?

Premier réflexe : aller fouiller dans /config, dans claude.ai/settings, dans claude.ai/admin-settings. Bonne demi-heure perdue à chercher un toggle qui n'existe pas. La feature est gated server-side via GrowthBook, le système de feature flags d'Anthropic. Plus précisément par un flag interne nommé tengu_ccr_bridge (ne me demande pas d'où sort le nom).

En creusant les issues GitHub (#34528, #29569) et l'analyse minifiée du binaire par la communauté, on tombe sur la vraie cause.

Le code coupable

Quelque part dans le binaire claude, une fonction Pv() décide si le client doit interroger le service de feature flags :

// Reconstitué depuis le code minifié
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 // ← retourne toujours false pour les features gated
}

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

Concrètement : si DISABLE_TELEMETRY=1 est set (ou son alias CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC), le client ne va même pas demander au serveur. Il assume que toutes les features gated sont à false. Remote Control disparaît, le message d'erreur tombe. Sans prévenir.

Ce qui me dérange dans ce design

Cette fonction mélange deux trucs qui n'ont rien à voir :

• "Je ne veux pas envoyer d'analytics" (préférence privacy parfaitement légitime)
• "Je suis un client qui ne peut pas joindre Anthropic" (cas Bedrock, Vertex, Foundry)

Quand je désactive la télémétrie, je veux couper l'upload d'analytics. Pas couper la lecture des flags qui décident de ce que mon abonnement Max 200$ a le droit de faire. Ce sont deux endpoints, deux usages, deux questions de design différentes. Ici ils se retrouvent gatés par le même booléen. C'est un peu n'importe quoi.

Plusieurs PRs poussent pour scinder ça côté Anthropic. En attendant, à nous de connaître le piège.

Ce qui est safe vs ce qui casse

J'avais quatre variables d'opt-out dans mon settings.json :

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

Verdict après lecture du code :

Piège typique : DISABLE_NON_ESSENTIAL_MODEL_CALLS ressemble visuellement à CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC (à un underscore et trois lettres près). Sauf que ce sont deux variables différentes avec deux effets différents. C'est DISABLE_TELEMETRY qui casse Remote Control, pas l'autre. J'ai failli supprimer la mauvaise.

La procédure de fix qui marche

Bon, voici ce qui m'a finalement débloqué :

1. Retirer DISABLE_TELEMETRY (et CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC si tu l'as) de ~/.claude/settings.json :

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

2. Vérifier qu'elle n'est pas non plus dans le shell :

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

3. Fermer complètement le terminal. La variable est encore exportée dans l'env du shell parent, donc relancer claude dans la même fenêtre ne suffit pas. Et si tu es dans un terminal intégré IDE (VS Code, Cursor), tue toutes les instances pour purger l'env hérité.

4. Rafraîchir le cache de feature flags côté client en réauthentifiant :

claude
# dans la session :
/logout
/login   # OAuth claude.ai, surtout PAS API key

5. Tester :

claude remote-control

Si tout est bon :

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)

Choix du mode spawn : same-dir ou worktree

Premier lancement, Claude Code te pose une question :

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

Mon raisonnement :

• same-dir : toutes les sessions lancées depuis mobile bossent dans le dossier courant. Simple. Mais si tu lances 2 sessions en parallèle, elles peuvent se marcher dessus sur les mêmes fichiers.
• worktree : chaque session a son propre git worktree isolé sur une branche dédiée. Parallélisme safe, avec l'overhead qui va avec (worktrees à nettoyer, branches à merger après).

Pour ce blog où j'écris en série, same-dir largement suffisant. Pour une codebase où tu veux laisser mobile traiter des tickets pendant que tu bosses sur autre chose au bureau, worktree devient pertinent. Tu peux switcher en cours de route avec la touche w, ou redémarrer avec --spawn=worktree.

Workflow détaché : tmux pour ne pas bloquer un terminal

Par défaut, claude remote-control mobilise ton terminal en avant-plan. Si tu fermes Windows Terminal, la session crève. Vu que je ferme Windows Terminal toutes les heures (mauvaise habitude), il fallait une solution. tmux, évidemment.

# Créer une session tmux nommée "rc"
tmux new -s rc

# Dans tmux : lancer le remote
claude remote-control

# Détacher (Ctrl+B puis D) : le terminal se ferme, le remote continue
# Pour revenir plus tard :
tmux attach -t rc

Avec ça, le remote vit en background tant que la machine est allumée. Je peux fermer Windows Terminal, ouvrir Steam, faire ma vie. Le téléphone reste connecté. Le jour où je veux reprendre en CLI, tmux attach -t rc et hop.

Et trois alias dans ~/.bashrc pour pas avoir à retaper :

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'

Ce qui marche, ce qui ne marche pas (encore)

Ça marche :

• Reprendre n'importe quelle session lancée depuis le remote sur mobile ou desktop
• Édition de fichiers en direct (les modifs apparaissent sur les deux écrans)
• Exécution de commandes bash, lecture de logs
• MCP servers locaux disponibles (Trello, Tavily, etc., tous ceux configurés en local)
• Notifications push quand une tâche longue se termine

Ça ne marche pas (ou pas encore) :

• Reprendre une session antérieure lancée hors remote. Les vieilles JSONL en ~/.claude/projects/ restent invisibles depuis mobile. Seul ce que tu lances via remote-control est accessible.
• Bosser sans connexion internet (forcément, c'est un bridge cloud).
• Garder la session si la machine s'éteint ou si WSL2 est mis en pause par Windows (le processus claude doit rester vivant).

Sur ce dernier point, c'est insidieux : Windows 11 met agressivement WSL2 en pause après quelques minutes d'inactivité. Tu crois que ta session tourne, et en fait ta VM Linux est gelée. Solution : créer %UserProfile%\.wslconfig avec :

[wsl2]
vmIdleTimeout=-1

Pour désactiver complètement l'idle timeout. J'ai mis 3 jours à comprendre pourquoi mes sessions tombaient quand je laissais mon laptop tranquille un peu trop longtemps.

Voilà

Remote Control, ça m'a vraiment débloqué pour bosser depuis le canapé ou le RER. Une commande, un QR code, et le téléphone devient un client Claude Code propre. Sans bricolage SSH, sans Tailscale, sans usine à gaz. Surtout, le code reste sur la machine.

Le piège DISABLE_TELEMETRY, c'est une leçon que je vais garder : sur Claude Code, dès qu'une feature payée ne marche pas, vérifier d'abord ses variables d'opt-out avant de blâmer Anthropic. Si tu veux faire le minimum syndical privacy sans rien casser, DISABLE_ERROR_REPORTING + DISABLE_NON_ESSENTIAL_MODEL_CALLS + CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY couvrent 95% du besoin sans toucher aux flags GrowthBook.

J'espère qu'Anthropic finira par découpler analytics et flag fetch. C'est pas la fin du monde, mais c'est le genre de gotcha qui fait perdre une demi-heure à des gens. Comme moi.