Claude + Codex en el mismo proyecto con worktrees de Git (2026)

¿Quieres que Claude y Codex trabajen en una misma app sin sobrescribir los archivos del otro? Los worktrees de Git dan a cada sesión su propia copia de trabajo y rama. Esta guía continúa mi artículo sobre cómo usar dos cuentas de Claude en un Mac: las cuentas separan los inicios de sesión; los worktrees, las carpetas de código. Resuelven problemas distintos.

Qué separa un worktree

Un worktree es otra copia de trabajo vinculada al mismo repositorio Git. Cada copia tiene sus propios archivos y rama, aunque comparte el historial de commits. Así, dos agentes pueden editar en paralelo. No separa credenciales, variables de entorno, bases de datos, servicios en ejecución ni destinos de despliegue. Trátalo como un espacio de trabajo del código, no como un límite de seguridad. Una rama tampoco publica nada por sí sola: el despliegue sigue dependiendo de tu proceso habitual.

Prepara puntos de partida limpios

Empieza en un repositorio Git con Git instalado. Consulta el estado y revisa todos los cambios. Confirma solo la base compartida que quieras conservar y añade rutas concretas; no prepares todo a ciegas. Los ejemplos parten de HEAD, así que los cambios sin confirmar no pasan a las nuevas copias.

git status --short
git worktree add -b ai/ui ../my-app-ui HEAD
git worktree add -b ai/backend ../my-app-backend HEAD

Después, comprueba la lista de worktrees y las dos carpetas. Git comparte el historial, pero la configuración del proyecto puede faltar: dependencias, archivos ignorados, cachés de compilación y ajustes locales requieren atención en cada copia. Usa credenciales de desarrollo aprobadas y datos de prueba; nunca copies secretos de producción automáticamente. Asigna puertos distintos a los servidores simultáneos y, si ambos escriben datos, separa las bases o esquemas de prueba y los identificadores de fixtures. Puede bastar con unos procesos locales o un servicio simulado; no hace falta contenerizar toda la pila.

Abre la herramienta en la carpeta correcta

Usa la carpeta de interfaz creada con Git para Claude Code y la de backend para Codex. Abre cada una como un proyecto local y confirma el directorio de trabajo antes de asignar tareas. Esta guía presupone que las dos herramientas ya están instaladas y tienen la sesión iniciada.

Las dos herramientas también ofrecen flujos con worktrees gestionados (Claude, Codex). Úsalos como alternativa a crear las carpetas manualmente, sin crear un segundo worktree para la misma tarea.

Acordad la interfaz antes de repartir el trabajo

Elige tareas que puedan avanzar por separado. Por ejemplo, Claude se encarga de la rama de interfaz y crea una pantalla y un cliente de API; Codex trabaja en la rama backend e implementa el endpoint. Antes de empezar, acordad método y ruta, campos de petición y respuesta, autenticación, errores de validación y un fixture de prueba. Cada agente debe ser responsable de su worktree y las personas deben asignar explícitamente los archivos compartidos.

1. Claude · rama de interfaz
2. Contrato de API acordado
3. Codex · rama backend
4. Revisar e integrar

Las carpetas separadas protegen los cambios; acordar el contenido de la respuesta mantiene alineadas las dos partes.

Un fallo típico: la interfaz lee items, pero el endpoint devuelve results. Git puede integrar esos cambios sin conflicto de texto y, aun así, la función falla. Acordad la estructura de la respuesta antes de trabajar en paralelo y verificadla en ambas implementaciones.

Revisa, integra y después limpia

1. Inspecciona cada diff. Revisa los archivos modificados, la configuración, las migraciones y el acceso a datos. Ejecuta las comprobaciones que cubren el comportamiento acordado; el mensaje de fin de un agente no es una prueba.
2. Integra una rama cada vez. Integra una rama revisada y ejecuta las comprobaciones correspondientes; después integra la segunda. Cuando estén ambas, prueba la interfaz contra el endpoint real.
3. Comprueba el comportamiento, no solo Git. Una integración limpia no detecta campos incompatibles, reglas de autenticación ni supuestos sobre servicios compartidos. Prueba el límite con el fixture.

Esta revisión requiere el mismo criterio que revisar código de apps generado con IA o coordinar un equipo de programación: la responsabilidad clara ayuda, pero una persona debe revisar el comportamiento integrado.

Antes de limpiar, consulta el estado y los commits recientes de cada copia y confirma qué está integrado. Lista los worktrees y elimina solo la ruta final prevista; deja que Git proteja el trabajo sin confirmar. No uses rm -rf ni el borrado forzado como limpieza habitual.

Si una app se acerca al lanzamiento, nuestra auditoría de código revisa arquitectura, comportamiento crítico, límites de datos y evidencias de lanzamiento según el alcance real del producto.