En un momento en el que cada vez más desarrolladores alternan entre el portátil, el móvil y el escritorio, la promesa de “continuar donde lo dejaste” se ha convertido en una obsesión tecnológica. Anthropic, la compañía detrás de Claude, está empujando esa idea un paso más allá con Claude Code en la web, un entorno pensado para lanzar tareas de programación desde el navegador o la app y dejarlas “trabajando” de forma asíncrona. En ese ecosistema ha empezado a circular un detalle que muchos usuarios aún no conocen: un comando de terminal, claude --teleport, capaz de trasladar una sesión remota al entorno local para seguir desde el PC.
La palabra “teleport” no es casual. En la práctica, este mecanismo actúa como un puente entre el Claude Code ejecutado en la nube (con interfaz web y móvil) y el Claude Code de la línea de comandos en la máquina del usuario. La utilidad es obvia: iniciar un encargo rápido en el teléfono —por ejemplo, “arregla este bug y abre un pull request”— y, al volver al escritorio, traer el trabajo al repositorio local para revisar, depurar o rematar cambios con herramientas propias.
Qué es Claude Code en la web y por qué importa el “salto” al terminal
Claude Code en la web funciona como un agente de programación con Inteligencia Artificial que se ejecuta en infraestructura cloud gestionada por Anthropic. El usuario conecta su cuenta de GitHub, selecciona un entorno y plantea la tarea: desde resolver un fallo hasta preparar una mejora con tests. Por debajo, el sistema clona el repositorio, prepara el entorno y ejecuta comandos como si el agente estuviera en una terminal. Al finalizar, los cambios se suben a una rama y se puede abrir un pull request. La propia documentación lo presenta como una manera de trabajar “en movimiento” y, especialmente, de poder vigilar o guiar tareas desde la app de iOS cuando uno está lejos del portátil.
Aquí aparece el elemento diferencial: la posibilidad de pasar una sesión desde la web al terminal. Es un giro importante porque reconoce un patrón real en los flujos de trabajo actuales: delegar tareas repetitivas o largas en la nube, pero conservar el control final en local, donde están los linters propios, el IDE, los secretos gestionados por la empresa o simplemente la comodidad del entorno habitual.
El comando claude --teleport: qué hace y cómo se usa
Aunque el comando se menciona en conversaciones de la comunidad desde hace meses, no siempre aparece de forma destacada en la documentación principal del CLI, lo que alimenta la idea de que se trata de una función “poco publicitada”. Aun así, su existencia es real: aparece referenciada en notas de cambios de Claude Code y en incidencias públicas del repositorio.
El uso habitual parte de un botón en la interfaz web: “Open in CLI”. Según la documentación oficial, el flujo está diseñado para que el usuario copie un comando generado por la web y lo ejecute en su terminal dentro de un clon local del repositorio correspondiente. En ese proceso, Claude Code hace dos cosas clave:
- Protege el trabajo local existente: si hay cambios sin commit, se guardan temporalmente (stash) para evitar conflictos.
- Carga la sesión remota: el terminal “importa” el estado de esa sesión para continuar trabajando desde la máquina del usuario.
En términos sencillos: se trata de pasar del “Claude en la nube” al “Claude en tu repo”, sin obligar a recomenzar la conversación ni replicar manualmente lo ya hecho.
Simon Willison, conocido por documentar herramientas de desarrollo y su impacto real, describió este “teleport” como una forma de copiar el historial de la conversación y los ficheros editados a la instancia local del CLI para tomar el control en la máquina propia. Es un matiz relevante: no solo se trata de leer un resultado final, sino de trasladar contexto y trabajo intermedio a un entorno donde el desarrollador puede seguir iterando.
Por qué a veces falla: lo que cuentan los bugs (y lo que revelan)
Como suele ocurrir con funciones que conectan piezas distintas —cloud, repositorios, autenticación, estado de sesión—, el “teleport” no está exento de fricción. Y precisamente por eso resulta útil mirar los fallos reportados públicamente: dibujan el mapa de riesgos reales.
1) Autenticación caducada (error 401)
Uno de los problemas más repetidos es el fallo al recuperar la sesión por un error de autenticación. Un reporte describe el caso típico: ejecutar claude --teleport session_... y recibir un 401, que luego se resolvió tras volver a autenticarse con el comando /login. En la práctica, es el recordatorio de siempre: si la sesión web va por delante de las credenciales locales, el puente se rompe.
2) El repositorio “no coincide” con lo que espera Claude
Otro bug apunta a un detalle muy de sysadmin: el formato del remoto Git. Hay casos en los que --teleport rechaza la ejecución con un mensaje del estilo “debes ejecutarlo desde un checkout de X/Y”, simplemente porque el repositorio fue clonado usando un alias SSH personalizado (por ejemplo, un Host distinto para GitHub en el ~/.ssh/config). El comando valida dónde está el usuario y, si no reconoce el patrón del remoto, concluye que no es el repositorio correcto.
3) Errores 400 y problemas de concurrencia de herramientas
También hay informes de errores 400 vinculados a “tool use concurrency”, que se manifiestan cuando la sesión remota llega con un estado interno que el CLI no puede rehidratar limpiamente. En algunos casos, se sugieren acciones como “rewind” para recuperar conversación, aunque la experiencia real puede variar según versión.
4) Diferencias entre lo que se ve en la web y lo que llega al CLI
Existe al menos un reporte que advierte que ciertos “follow-up prompts” añadidos mientras la tarea estaba en marcha en la web no se reflejaban al teletransportar la sesión. Esto matiza la promesa de “continuidad perfecta”: la intención es clara, pero aún hay bordes en los que el traspaso no captura el 100 % de la interacción tal y como el usuario la recuerda.
No es casual que el changelog de Claude Code mencione mejoras específicas en los mensajes de error y validaciones relacionadas con claude --teleport. Es una señal de que la función está viva, se usa y se está puliendo.
Qué cambia para el día a día de equipos y desarrolladores
El valor de claude --teleport no está en el “truco” en sí, sino en lo que representa: el paso de los chatbots a flujos de trabajo híbridos, donde la Inteligencia Artificial puede operar en la nube mientras el humano conserva la última palabra en local. Es una arquitectura que encaja con la realidad del desarrollo moderno: repositorios en GitHub, tareas asíncronas, revisiones por pull request y, cada vez más, la necesidad de retomar el hilo desde el dispositivo que toque.
Pero también obliga a ser honestos: la comodidad se paga con complejidad. Autenticación, remotos Git, estados de sesión y diferencias entre interfaces son el tipo de “detalles” que, en el mundo real, deciden si una función se convierte en hábito… o en anécdota.
Preguntas frecuentes
¿Cómo pasar una sesión de Claude Code desde el móvil al PC sin perder el contexto?
La vía prevista es iniciar la tarea en Claude Code en la web o iOS, pulsar “Open in CLI” y ejecutar el comando que ofrece en una carpeta local donde el repositorio esté clonado.
¿Qué hace exactamente claude --teleport en el repositorio local?
Según la documentación y experiencias compartidas, carga la sesión remota en el CLI y, si hay cambios locales sin guardar, los “aparta” temporalmente para evitar conflictos antes de continuar.
¿Por qué claude --teleport dice que no estoy en el repositorio correcto si sí lo estoy?
Puede ocurrir si el remoto Git usa formatos no estándar (por ejemplo, alias SSH personalizados). En esos casos, el CLI puede no reconocer el patrón del remoto y bloquear el traspaso.
¿Qué errores son más comunes al usar claude --teleport y cómo se solucionan?
Los más habituales son fallos de autenticación (token caducado) que suelen resolverse con /login, y errores de validación del repositorio o problemas puntuales de estado de sesión que dependen de la versión instalada.
