Los dos tipos de Handoff
Handoff llegó en dos pasos. Mover chats entre Local y Worktree fue lo primero, a principios de marzo de 2026; el resumen semanal de OpenAI dice que "hizo posible mover un chat activo preservando su contexto". Mover chats entre hosts le siguió en junio: "Chat handoff mueve un chat y su estado de Git entre tu ordenador local y un host remoto conectado".
Local y Worktree
Un worktree es un segundo checkout de tu repositorio. La página de worktree de OpenAI plantea la relación de esta manera: "Puedes pensar en Local como el primer plano y en Worktree como el segundo plano. Handoff te permite mover un chat entre ellos".
Para traer un chat al primer plano, seleccionas Hand off en el encabezado del chat y lo mueves a Local. También puedes ir en la otra dirección, moviendo un chat de Local a un worktree para que Codex siga trabajando mientras tú haces otra cosa.
Una razón por la que Handoff es importante es una regla de Git. La página de worktree lo explica: "Git solo permite que una rama esté en checkout en un lugar a la vez". Handoff se encarga de los pasos de Git para que no choques con ese muro cuando quieras ver el trabajo localmente.
Un detalle facilita el viaje de ida y vuelta: "Cada chat mantiene el mismo worktree asociado a lo largo del tiempo. Si devuelves el chat a un worktree más tarde, Codex lo devuelve a ese mismo entorno de segundo plano para que puedas retomar donde lo dejaste".
Entre hosts
Un host remoto es otro ordenador al que se conecta la aplicación de escritorio, como un host SSH. La página de conexiones remotas describe el caso de uso: "Úsalo para empezar a trabajar localmente, continuar en un worktree en un ordenador remoto y traer el chat de vuelta más tarde".
Abres el chat, seleccionas la ubicación de ejecución actual en el pie de página del chat, eliges el host de destino, revisas el destino y la rama, y seleccionas Hand off. En el otro lado, según OpenAI, "Codex crea o reutiliza un worktree en el host de destino, transfiere el chat y el estado de Git, y cambia el chat a ese host".
Qué se mueve con el chat
La conversación. El chat en sí se mueve, por lo que el siguiente mensaje continúa el mismo hilo. No tienes que volver a explicar la tarea.
El estado de Git. Handoff gestiona las operaciones de Git entre los dos checkouts. Para hosts remotos, OpenAI dice que transfiere "el chat y el estado de Git".
El enlace de retorno. Para los worktrees, cada chat mantiene el mismo worktree, por lo que devolverlo lo sitúa de nuevo en ese entorno.
Qué se queda donde estaba
Esta es la parte que vale la pena leer antes de tu primer handoff.
Archivos ignorados
Debido a que Handoff utiliza Git, los archivos que Git ignora no se transfieren. La página de worktree dice: "Dado que Handoff utiliza operaciones de Git, cualquier archivo que forme parte de tu archivo .gitignore no se moverá con el chat a menos que Codex los copie en un worktree gestionado local con .worktreeinclude".
Eso cubre archivos como .env y secretos locales. Un archivo .worktreeinclude en la raíz del repositorio enumera las rutas ignoradas que Codex debe copiar cuando crea un worktree gestionado. OpenAI señala que este comportamiento "se aplica a los worktrees gestionados de la aplicación de escritorio ChatGPT local, no a los worktrees remotos o worktrees de Git que crees tú mismo desde la línea de comandos". Para un host remoto, planea configurar esos archivos allí tú mismo.
Se incluye una excepción por defecto: "Codex copia automáticamente un AGENTS.override.md ignorado en los worktrees gestionados locales, por lo que no necesitas listarlo en .worktreeinclude".
La configuración de la otra máquina
Cuando un chat se mueve a un host remoto, se ejecuta con el entorno de ese host. La página de conexiones remotas es clara sobre lo que eso significa en general: "El acceso remoto utiliza los proyectos, chats, archivos, credenciales, permisos, plugins, Computer Use, configuración del navegador y herramientas locales del host conectado".
Por lo tanto, los plugins, credenciales y herramientas disponibles después del handoff son los del host de destino, no los de tu portátil.
Memorias e instrucciones personales
Las memorias de Codex están vinculadas a una máquina. La página de memorias describe el ajuste como activar o desactivar la función "para la máquina seleccionada", y los archivos de memoria residen en ~/.codex/memories/ en esa máquina. La extensión del IDE sigue el mismo patrón: "utiliza el almacenamiento de memoria local del host de Codex conectado".
Tu instrucciones globales funcionan de la misma manera. Codex lee la guía global del directorio de inicio de Codex, ~/.codex por defecto, en cualquier máquina en la que se ejecute.
La documentación de Handoff no describe la copia de memorias o de un AGENTS.md global entre hosts. Por lo tanto, después de que un chat se mueva a un host remoto, espera que funcione con las memorias e instrucciones globales de ese host, si las hay. Un AGENTS.md del repositorio que esté confirmado en Git estará presente en ambos lados.
Lo que Handoff no puede hacer
La documentación enumera algunos límites.
- Necesita un proyecto coincidente. "Antes de realizar el handoff de un chat, conecta el host de destino y guarda un proyecto para el mismo repositorio de Git en ese host". Si el proyecto es un subdirectorio, guarda el mismo subdirectorio en ambos hosts. "Codex solo muestra destinos con un proyecto guardado coincidente".
- Interrumpe el trabajo en curso. "Si el chat se está ejecutando, el handoff interrumpe la respuesta actual antes de transferirla".
- No va a la nube. Puedes pedirle a Codex en otro chat que transfiera un chat con nombre, pero "Codex no puede transferir el chat que realiza la solicitud, y el handoff a un entorno de nube de Codex no es compatible".
- Una rama, un lugar. Si creas una rama en un worktree con Create branch here, no puedes hacer checkout de ella localmente al mismo tiempo. El consejo de OpenAI: "Si planeas hacer checkout de la rama localmente, usa Handoff para mover el chat a Local en lugar de intentar mantener la misma rama en checkout en ambos lugares a la vez".
Para el trabajo que quieras ejecutar en la nube de OpenAI, nuestra guía para preparar un entorno de nube de Codex con el contexto de tu proyecto cubre esa ruta.
Lo que la gente intenta primero
Iniciar un nuevo chat en la otra máquina. Funciona, pero pierdes el hilo y pasas los primeros mensajes volviendo a explicarlo todo.
Hacer checkout de la rama del worktree localmente. Git lo rechaza porque la rama ya está en checkout en el worktree. Handoff es el camino previsto.
Esperar que el host remoto tenga tu configuración local. En un host remoto, el chat utiliza los archivos, plugins, credenciales y memorias de ese host, no los de tu portátil.
Realizar el handoff de un chat en ejecución a mitad de la tarea. Handoff detiene la respuesta actual primero, así que deja que llegue a un punto de parada.
La solución: Preparar ambos lados, realizar el handoff en un punto de parada y luego confirmar el contexto
Paso 1: Preparar el destino antes del handoff
Para un worktree, añade un archivo .worktreeinclude que enumere los archivos ignorados que necesita un nuevo checkout, como los archivos .env. Para un host remoto, conéctalo, guarda un proyecto para el mismo repositorio y configura su entorno: archivos ignorados, credenciales, plugins y cualquier instrucción global en la que confíes. Si usas memorias, decide si las quieres también en ese host; la página de memorias explica cómo activarlas por máquina.
Paso 2: Realizar el handoff cuando el chat haya llegado a un punto de parada
Deja que la respuesta actual termine. Luego, pide a Codex un breve resumen de la situación: qué se ha hecho, qué es lo siguiente y cualquier decisión que haya tomado por el camino. Ese resumen está en el chat, por lo que se mueve con él, y le da al chat en el otro lado un punto de partida limpio. Luego usa Hand off.
Paso 3: Comprobar qué puede ver el chat en el otro lado
Después del handoff, pide a Codex que resuma las instrucciones que está siguiendo y confirme que puede ejecutar el proyecto. Si falta algo, suele ser un archivo ignorado, una credencial o una instrucción global que reside en la otra máquina. Corrígelo en el destino y continúa. Nuestra guía para evitar que Codex se salte las reglas de AGENTS.md cubre la comprobación de instrucciones con más detalle.
Configurar esto en MemoryLake
Handoff mueve un chat y su código. El contexto que rodea al trabajo, cómo te gusta que se hagan las cosas, qué decisiones están tomadas, cuáles son las convenciones del proyecto, reside en parte en el chat, en parte en archivos de una máquina y en parte en memorias que se quedan en esa máquina.
MemoryLake es una capa de memoria para mantener ese contexto en una sola lista que tú mantienes, disponible para Codex y los otros asistentes que conectes, como ChatGPT y Claude Code.
Tú mismo escribes las entradas, con tus propias palabras. No se lee nada, ni se escribe ni se borra de tus chats de Codex, tus memorias de Codex, tus worktrees, tus hosts remotos o el almacenamiento de cualquier proveedor. Para repositorios de trabajo, sigue la política de tu organización sobre lo que guardas fuera de ellos.
Paso 1: Crear una clave API
Inicia sesión y genera una clave desde el panel de control. La clave pertenece a tu espacio de trabajo de MemoryLake y es independiente de tu cuenta de ChatGPT.
Paso 2: Sube tus primeras memorias
Empieza con el resumen del Paso 2 de la solución y las convenciones que de otro modo tendrías que configurar de nuevo en cada host. Un punto por entrada, con fecha y etiquetado con el repositorio al que se aplica.
Paso 3: Conecta tu IA y agentes
Conecta Codex y los otros asistentes que utilices. El mismo contexto estará disponible en tu portátil, en tu host remoto y en cualquier checkout en el que aterrice el chat.
Qué cambia esto en la práctica
La primera diferencia es que mover un chat deja de ser una apuesta. Sabes que la conversación y el estado de Git van con él, y sabes qué piezas locales no.
La segunda es que el destino está listo antes de que llegues. Los archivos ignorados están listados, el proyecto remoto está guardado y la configuración de la que dependes está en su lugar.
La tercera es que el contexto que te importa no depende de en qué máquina se ejecute el chat. Si te vas a mudar a un ordenador completamente nuevo en lugar de transferir un chat, nuestra guía para migrar tu configuración de Codex a un nuevo ordenador cubre todo el proceso.
Mejores prácticas para Codex Handoff
Usa un worktree para el trabajo en segundo plano y Local para revisarlo. Esa es la división para la que se diseñó Handoff.
Enumera los archivos de configuración ignorados en .worktreeinclude. De lo contrario, se quedarán atrás.
Guarda proyectos coincidentes en cada host. Handoff solo ofrece destinos que tengan uno.
Realiza el handoff en un punto de parada. Una respuesta en ejecución se interrumpe.
Pide un resumen antes de moverte. Viaja con el chat y ayuda en el otro lado.
Configura las memorias por máquina. Codex las establece por máquina. Nuestra guía para activar las memorias locales de Codex cubre los ajustes.
No mantengas una rama en checkout en dos lugares. En su lugar, realiza el handoff del chat.
Conclusión
Codex Handoff mueve un chat y su estado de Git entre tu checkout local y un worktree, o entre tu ordenador y un host remoto conectado. Es la forma de traer el trabajo en segundo plano al primer plano, o enviar el trabajo a otra máquina, sin iniciar una nueva conversación.
No mueve los archivos ignorados, a menos que .worktreeinclude los copie en un worktree gestionado local, y en un host remoto funciona con los plugins, credenciales, memorias e instrucciones globales de ese host. No puede realizar el handoff a un entorno de nube de Codex. Prepara el destino, realiza el handoff en un punto de parada y comprueba qué puede ver el chat cuando llegue. Si también usas Claude Code, nuestra guía sobre si los worktrees de Claude Code comparten memoria cubre la misma cuestión para ese caso.