Claude Code es excelente para leer una base de código extensa y mantener un plan a través de muchos archivos. Codex es excelente para cambios acotados y guiados por pruebas. Muchos ingenieros terminan queriendo ambos en el mismo repositorio: uno redactando una refactorización mientras el otro refuerza una suite de pruebas inestable. En el momento en que lo intentas, el mismo directorio de trabajo se convierte en el problema. Dos herramientas distintas, dos CLIs distintas, una carpeta en la que ambas escriben.
Esta guía recorre la configuración paso a paso, nombra el modo de fallo en cada etapa y muestra dónde dos terminales dejan de escalar. La mitad de aislamiento es un problema resuelto con los worktrees de git. La mitad de coordinación, saber qué herramienta está en qué y mantener cada cambio revisable, es donde una capa neutral respecto al entorno de ejecución como Sharkly toma el control.
Sharkly no es un reemplazo de Claude Code ni de Codex. Añade la capa compartida de Task, Computer, contexto y revisión alrededor de las herramientas de ejecución que ya usas, de modo que una sesión de Claude Code y una sesión de Codex se convierten en dos asignaciones dentro de un mismo flujo de trabajo en lugar de dos terminales que tienes que vigilar.
Por qué querrías ejecutar Claude Code y Codex en el mismo repositorio
Hay tres razones que aparecen una y otra vez, y no son el mismo problema.
Fortalezas distintas en tareas distintas. Envías el trabajo de contexto amplio (rastrear este bug por todo el módulo, planificar esta migración) a un agente y el trabajo acotado y verificable (hacer que esta prueba pase, ajustar esta función) al otro. Emparejar la herramienta con la tarea es un tema en sí mismo; consulta qué modelo para qué tarea de programación.
Una comparación cara a cara sobre trabajo real. El único benchmark honesto es tu base de código, no una tabla de posiciones. Ejecutar ambos sobre el mismo ticket y comparar los diffs te dice más que cualquier puntuación publicada. Cubrimos el método en cómo comparar agentes de programación en tu propia base de código.
Ya pagas por ambos. Muchos equipos ya tienen una suscripción a Claude y un asiento de Codex o de API. La neutralidad respecto al proveedor es el punto: tu flujo de trabajo debería sobrevivir a cualquiera de las herramientas que lance el siguiente mejor modelo, sin necesidad de reconstruirlo.
Cualquiera que sea la razón, el fallo es idéntico. Dos agentes en una misma carpeta son dos escritores editando un mismo documento sin ningún bloqueo. Uno cambia la rama por debajo del otro, o reformatea un archivo a mitad de edición, y acabas con diffs aplicados a medias que no tienen ningún sentido.
Paso 1: dale a cada agente su propio worktree
El git worktree soluciona la colisión de raíz. Un repositorio puede tener varios directorios de trabajo extraídos a la vez, cada uno en su propia rama, compartiendo una única base de datos .git. En lugar de una sola carpeta por la que ambas herramientas se pelean, tienes una por tarea.
# One checkout per task, each on its own branch
git worktree add ../app-refactor -b agent/refactor
git worktree add ../app-tests -b agent/tests
git worktree list
Apunta una herramienta distinta a cada directorio:
cd ../app-refactor && claude # Claude Code on the refactor
cd ../app-tests && codex # Codex on the test suite
Modo de fallo si omites esto: ambas herramientas hacen cd al mismo repositorio, compiten por los mismos archivos y una sobrescribe en silencio el trabajo sin confirmar de la otra. Los worktrees hacen que eso sea físicamente imposible. La limpieza posterior tiene sus propias aristas afiladas; gestionar worktrees sin el dolor de la limpieza cubre git worktree remove y el problema de las ramas obsoletas.
Paso 2: apunta cada herramienta a las instrucciones correctas
Claude Code y Codex leen archivos de proyecto distintos. Claude Code busca CLAUDE.md; Codex lee AGENTS.md. Si tu repositorio solo tiene uno de ellos, un agente trabaja a ciegas respecto a tus convenciones.
Conserva ambos y mantenlos coherentes. El patrón fiable es escribir las reglas compartidas una sola vez y hacer que cada punto de entrada las incluya:
<!-- CLAUDE.md and AGENTS.md both start with -->
See ./docs/agent-conventions.md for build, test, and style rules.
# Verify each tool actually loads its file before you turn it loose
claude --version # Claude Code reads CLAUDE.md from the worktree root
codex --version # Codex reads AGENTS.md from the worktree root
Modo de fallo si omites esto: Codex sigue una configuración de lint mientras Claude Code sigue otra, y cada merge se convierte en una pelea de estilo que nadie dejó por escrito. Una nota personal viene al caso aquí: un token de instalación no lleva tus convenciones, y un archivo local en .gitignore no viaja al worktree. Pon las reglas compartidas en archivos rastreados, o cada nuevo worktree empezará vacío.
Paso 3: lanza y observa cómo se abre la brecha de coordinación
Con dos worktrees y dos archivos de configuración, la mecánica funciona. Tienes Claude Code en una rama y Codex en otra, sin que ninguno toque los archivos del otro. Para una tarde con dos agentes, esto aguanta.
La brecha se abre cuando levantas la vista del teclado. Cada sesión guarda su propio historial en su propia pestaña, invisible para la otra. Cuando la ejecución de Codex necesita saber qué ha cambiado ya la ejecución de Claude Code, no hay memoria compartida que consultar, así que tú te conviertes en la capa de integración. Los agentes terminan en momentos distintos y esperan en silencio a que alguien les dé instrucciones, así que «ejecutar ambos en paralelo» se degrada sin darse uno cuenta a «ir revisando cada uno en secuencia».
Escala esto más allá de dos. El siguiente movimiento natural es un script envoltorio que levante worktrees, lance la herramienta adecuada en cada uno y canalice la salida hacia paneles de tmux con nombre. Ayuda para un puñado de ejecuciones. Luego crece: nombres de ramas, limpieza, una forma de saber qué herramienta está en qué tarea, reintentos para la que se cayó. En poco tiempo mantienes un framework de orquestación frágil sostenido con bash, donde la mitad del estado vive en el historial del shell y la otra mitad en tu cabeza. Ejecutar muchos a la vez choca con el mismo muro tanto si los agentes son todos Claude Code, como en ejecutar varios agentes de Claude Code, como si son una mezcla.
Dónde dos terminales dejan de escalar
La prueba honesta para saber si has superado la configuración casera:
- ¿Puede un compañero de equipo ver qué están haciendo tus agentes ahora mismo, sin que tú le leas la terminal?
- Cuando Codex termina a las 2 de la tarde y necesita instrucciones, ¿algo te avisa?
- Cuando ambos agentes terminan a la vez, ¿hay una cola para revisar su trabajo, o solo estás tú y dos ramas?
Si las respuestas son no, la pieza que falta no es otro script de shell. Es una capa que asigne trabajo a cualquiera de las herramientas, muestre el estado en vivo y mantenga cada cambio revisable antes de fusionarlo. Eso es lo que un tablero de tareas aporta frente a las terminales en bruto.
Este es el límite que merece la pena enunciar con claridad. Claude Code y Codex se encargan de la ejecución. Una capa de comando gestiona la asignación, los Computers conectados, el contexto de la tarea, el progreso, los bloqueos, los resultados y la revisión humana en ambos. En Sharkly, asignas una Task a un Runtime de Claude Code y otra a un Runtime de Codex; cada una se ejecuta en su propio worktree aislado en un Computer conectado, y la ejecución, los bloqueos y los resultados vuelven a la línea de tiempo de la Task en lugar de desaparecer en terminales privadas.
La división del trabajo se mantiene limpia. Los agentes investigan, ejecutan, prueban e informan. Las personas marcan la dirección, conceden autoridad y aceptan el resultado. La automatización se detiene donde se requiere tu criterio, y te devuelve un diff con la evidencia de verificación adjunta. Conservas las herramientas que ya pagas, el uso de los modelos sigue pasando por las suscripciones y las claves de API configuradas en cada una, y obtienes un único lugar donde ver quién está en qué.
Usa la configuración manual cuando ejecutes uno o dos agentes durante una tarde y puedas mantener el estado en tu cabeza. Recurre a una capa compartida cuando otra persona necesite visibilidad, cuando el número supere lo que muestra una sola ventana de terminal, o cuando compares herramientas con la suficiente frecuencia como para que «qué ejecución produjo esta rama» deje de ser obvio.
Una lista de comprobación que puedes seguir hoy
Síguela de arriba a abajo la próxima vez que pongas ambas herramientas en un mismo repositorio:
- [ ] Crea un
git worktreepor tarea, cada uno en su propia rama. Nunca apuntes dos herramientas al mismo directorio. - [ ] Confirma tanto
CLAUDE.mdcomoAGENTS.md, cada uno apuntando a un único archivo de convenciones compartido en el código rastreado. - [ ] Verifica que cada herramienta carga su configuración desde la raíz del worktree antes de asignarle trabajo.
- [ ] Asigna una Task acotada por agente. El trabajo de contexto amplio a uno, el trabajo acotado y guiado por pruebas al otro.
- [ ] Decide de antemano tu punto de control de revisión: ninguna rama se fusiona hasta que una persona lea el diff y los resultados de las pruebas.
- [ ] Cuando pases de dos o tres ejecuciones simultáneas, deja de escalar el bash y traslada la asignación, el estado y la revisión a una sola capa.
Si quieres seguir usando tanto Claude Code como Codex en lugar de comprometerte con un solo ecosistema, ese es el problema en torno al cual está diseñado Sharkly. Descarga Sharkly, conecta un Computer y asigna tu primera Task al agente que mejor encaje con el trabajo.
Preguntas frecuentes
¿Pueden Claude Code y Codex editar los mismos archivos de forma segura? No en el mismo directorio. Dale a cada uno su propio git worktree para que trabajen en ramas separadas y luego fusiona mediante revisión. La concurrencia en el mismo directorio es donde se pierde el trabajo sin confirmar.
¿Necesito dos suscripciones? Necesitas lo que requiera cada herramienta. El uso de los modelos continúa a través de las suscripciones o claves de API configuradas en Claude Code y Codex; una capa de coordinación no cambia ni revende ese acceso.
¿Es una exageración un tablero de tareas para dos agentes? Para dos agentes que controlas en una sola sesión, basta con worktrees simples y dos terminales. El tablero se gana su lugar cuando un compañero de equipo necesita visibilidad o cuando el número de ejecuciones aumenta. Consulta las mejores herramientas para gestionar agentes de programación con IA en paralelo.
