El 25 de febrero de 2026, Anthropic anunció Remote Control para Claude Code. La idea: arrancas Claude Code en tu terminal, te vas al sofá con el móvil, y sigues la sesión desde claude.ai. Sin SSH. Sin tmux. Sin pantallitas de terminal remota.
Mola. En teoría.
Porque en la práctica, cuando lo activé (/rc en la terminal), me dio una URL, abrí el móvil, hice login… y claude.ai me soltó un «this feature is not active in your organization». Febrero de 2026, cuenta Max 5x, pagando religiosamente. Y nada.
Así que hice lo que cualquier persona razonable haría: ponerme a desmontar la API para entender qué está pasando por debajo.
Qué es Remote Control (la versión oficial)
En esencia: un puente entre tu CLI local y la web de claude.ai. La CLI de Claude Code sigue corriendo en tu máquina (con acceso a tu código, tu terminal, tus ficheros), pero tú puedes verla, aprobar tool calls y enviar mensajes desde cualquier navegador.
Anthropic lo presentó como «research preview«, solo para cuentas Max. La promesa es que puedes lanzar una tarea larga (/rc + tu prompt), cerrar el portátil, irte al gimnasio, y revisar el progreso desde el móvil.
La realidad, como veremos, es más matizada.
Lo que descubrimos por debajo
Cuando ejecutas /rc, Claude Code hace bastantes cosas entre bastidores. Y deja rastros. Muchos rastros. En ficheros JSONL, en debug logs, en la propia respuesta de la API. Vamos por partes.
1. El Bridge API
Lo primero que hace la CLI es registrar un «environment» contra la API de Anthropic:
POST https://api.anthropic.com/v1/environments/bridge
El payload incluye información sobre tu máquina:
{
"machine_name": "MacBook-Pro-de-Fernando",
"directory": "/Users/fernando/code/tokamak",
"branch": "main",
"git_repo_url": "https://git.frr.dev/frr/tokamak.git"
}
Y la respuesta te devuelve un environment_id, un environment_secret, y tu organization_uuid. Es un registro: «este ordenador, en este directorio, con esta sesión, está disponible para control remoto».
2. El WebSocket (no es polling)
Aquí viene lo interesante. La comunicación no es polling HTTP. Es un WebSocket bidireccional:
wss://api.anthropic.com/v1/session_ingress/ws/{session_id}
La CLI abre este WebSocket y se queda escuchando. Cuando tú, desde el móvil, escribes algo en claude.ai, el mensaje viaja por el WebSocket hasta tu CLI local. La CLI lo procesa (ejecuta herramientas, lee ficheros, lo que sea) y envía el resultado de vuelta por el mismo canal.
No es magia, pero es elegante. El WebSocket mantiene una conexión persistente, así que la latencia es mínima. No hay que estar preguntando «¿hay algo nuevo?» cada 5 segundos.
Anthropic lo llama HybridTransport internamente: HTTPS para el registro y las operaciones pesadas, WebSocket para la comunicación en tiempo real.
3. El polling de trabajo
Además del WebSocket, hay un endpoint de polling para cuando la conexión WebSocket se cae:
GET https://api.anthropic.com/v1/environments/{env_id}/work/poll
Es el fallback. Si el WebSocket se desconecta (WiFi inestable, laptop en sleep), la CLI puede volver a preguntar «¿tienes trabajo para mí?» vía HTTP normal. Belt and suspenders, que dicen los americanos.
4. Las trazas en disco
Y aquí está lo que más me interesa como constructor de herramientas. Cada sesión con /rc deja rastros en tres sitios:
En el JSONL de sesión (el fichero que Tokamak ya lee), aparece un evento nuevo:
{
"type": "bridge_status",
"subtype": "bridge_status",
"bridgeUrl": "https://claude.ai/code/session_01SjBW...",
"slug": "rapid-frozen-basilisk"
}
El campo slug es particularmente bonito: un nombre de tres palabras generado aleatoriamente para identificar la sesión de forma humana. «rapid-frozen-basilisk». Suena a nombre de operación de la CIA.
En los ficheros de telemetría, aparece un flag:
is_claude_code_remote: true
Y en el debug log (~/.claude/debug/{sessionId}.txt), aparece TODO:
Bridge API request: POST /v1/environments/bridge
Bridge API response: 200 { environment_id: "...", ... }
WebSocket connected: wss://api.anthropic.com/v1/session_ingress/ws/...
Es un volcado completo de cada interacción con el Bridge API. URLs, payloads, respuestas, estados del WebSocket. Un sueño para hacer reverse engineering.
Por qué no funciona (todavía)
Ahora la parte amarga. Todo esto que acabo de describir lo descubrí ejecutando /rc en mi terminal. La CLI se registró contra el Bridge API sin problemas. El WebSocket se conectó. El debug log se llenó de trazas.
Pero cuando intenté conectarme desde el móvil, claude.ai dijo que no.
Busqué en GitHub. Decenas de issues reportando exactamente lo mismo. «Remote Control not available in my organization.» Cuentas Max. Cuentas de pago. Todas con el mismo problema.
La respuesta de Anthropic es que es un «gradual rollout«. Dicho en cristiano: lo están activando cuenta por cuenta, no de golpe. Y en febrero de 2026, la mayoría de cuentas Max todavía no tienen acceso.
Es como cuando te enseñan el menú del restaurante con fotos preciosas, pides el plato estrella, y el camarero te dice «ah, ese todavía no lo servimos».
Lo que puedes hacer sin que funcione el Remote Control
Aquí viene la parte constructiva. Aunque no puedas usar Remote Control desde el móvil, la mera existencia de la API y las trazas que deja abre posibilidades interesantes para herramientas de terceros.
Detectar sesiones remotas
El campo slug en el JSONL y el flag is_claude_code_remote en telemetría permiten distinguir sesiones locales de sesiones remotas. Si estás construyendo un dashboard (como Tokamak), puedes mostrar: «esta sesión se controló desde el móvil entre las 14:00 y las 15:30».
Datos del Bridge como contexto
El registro contra el Bridge API incluye machine_name, directory, branch, git_repo_url. Si tienes múltiples máquinas o sesiones, el Bridge te da un inventario completo de dónde está corriendo cada instancia de Claude Code. Un Fleet View gratis.
WebSocket como canal de observación
El WebSocket es bidireccional. Hoy Anthropic lo usa para conectar claude.ai con tu CLI. Pero un cliente de terceros podría, en teoría, conectarse al mismo canal como observador. Ver los mensajes en tiempo real sin intervenir. Un session replay en directo.
Digo «en teoría» porque necesitarías el environment_secret que te da el Bridge API, y Anthropic podría (y probablemente lo hará) restringir quién puede conectarse. Pero la infraestructura está ahí.
Lo que esto dice sobre Anthropic
Dos cosas me llaman la atención.
Primera: la calidad técnica del Bridge API es alta. WebSocket con fallback a polling, secretos rotables, registro de entorno con metadatos de git, nombres humanos para sesiones. No es una chapuza. Lo han diseñado para escalar.
Segunda: la gestión del lanzamiento es… discutible. Anunciar una feature en el blog oficial, que la CLI la soporte, que deje trazas, que genere URLs funcionales… pero que no esté disponible para la mayoría de usuarios de pago. Eso genera frustración. Las decenas de issues en GitHub lo confirman.
Es un patrón que se repite en el mundo de la IA: mucho anuncio, poco rollout. Como si las empresas necesitaran generar hype antes de tener la infraestructura lista para servir a todos.
En resumen
Remote Control de Claude Code es una feature real, bien diseñada, con una API elegante por debajo. El Bridge API, el WebSocket, las trazas en disco — todo pinta a que lo han construido para quedarse.
Pero a día de hoy, 27 de febrero de 2026, la mayoría de usuarios Max no pueden usarlo. Los datos están ahí. La API responde. Tu CLI se registra y conecta. Y luego claude.ai te dice que no puedes pasar.
Si tienes una cuenta Max y te funciona: enhorabuena, eres de los elegidos. Si no: ten paciencia. O haz como yo y dedica la tarde a desmontar una API que no puedes usar. Que al menos aprendes algo.
Y si estás construyendo herramientas sobre Claude Code, toma nota de los endpoints y las trazas. Cuando esto se abra para todos, vas a querer estar preparado.
Read this article in English.
