Codex vs Claude Code, según los archivos de tu disco
No es un veredicto sobre cuál escribe mejor código. Es una descripción de cómo se comportan los dos en la práctica, escrita por quienes tuvieron que lograr que una sola ventana controlara a ambos.
Por qué esta comparación es distinta de las demás
La mayor parte de lo que se escribe sobre Codex vs Claude Code es un benchmark hecho en el portátil de alguien, y queda obsoleto en un mes porque ambos lanzan modelos más rápido de lo que nadie puede escribir sobre ellos. Esta página no hace eso. Si uno escribe mejor código que el otro es una pregunta sobre los modelos del día en que la haces, y no vamos a fingir que la vamos a resolver.
Lo que sí podemos contarte es de qué están hechos los dos programas, porque Vobuda tuvo que leer ambos para poder dibujar una barra de control sobre cualquiera de los dos. Dónde guarda cada uno sus sesiones, cómo llama a retomar una, dónde vive su lista de modelos, cómo anuncia el modo en el que está. Son datos de tu propio disco, cambian despacio, y son los que determinan cómo encaja cada uno en un día de trabajo.
La versión corta: Claude Code es el más legible de los dos desde fuera. Escribe sus modelos en un archivo, guarda sus sesiones en una carpeta por proyecto, y usa un flag para retomar una. Codex se guarda más cosas para sí mismo. Cambia de modelo mediante un selector propio, así que lo honesto es abrir ese selector y leer lo que muestra en lugar de mandar una lista que estará mal.
Dónde guarda cada uno qué
Todo lo que hay en esta tabla está en la máquina que tienes delante, y puedes ir a comprobarlo.
| Claude Code | Codex | |
|---|---|---|
| Sesiones anteriores | Una carpeta por proyecto bajo ~/.claude/projects | Un índice, ~/.codex/session_index.jsonl, que nombra cada hilo |
| Abrir una antigua | --resume <id> | resume <id> |
| Retomar la última | --continue | resume --last |
| Skills | ~/.claude/skills, más la carpeta correspondiente en el proyecto | ~/.codex/skills, más la carpeta correspondiente en el proyecto |
| Lista de modelos | Su propio archivo, escrito según se lo indica su servidor, así que un modelo nuevo aparece el mismo día que se lanza | Su propio selector, que el menú abre y lee fila por fila |
| Fijar el modelo | /model para el modelo, /effort para el nivel | Su propio selector /model, y luego un nivel para cada modelo |
| Sus ajustes | settings.json | config.toml |
| Qué dice su línea de estado | Opus 5.5 con esfuerzo alto, Claude Max | gpt-5.6-terra medium |
| Cómo se ve el proceso | claude | node, porque Codex se ejecuta como node |
Revisado en septiembre de 2026 sobre instalaciones actuales de ambos. Su propia documentación es la autoridad; esto es lo que parecen los dos desde una ventana que tiene que controlarlos.
Dos carpetas, de donde sale todo lo de la tabla anterior
Ningún agente esconde nada de esto. La barra de control de Vobuda lee exactamente estos archivos, por eso puede mostrar una lista de modelos que nosotros nunca escribimos.
settings.json modelo, esfuerzo, permisosprojects/ una carpeta por proyecto <project>/ sus sesiones, la más reciente al finalskills/ las tuyas, más las propias del proyectohistory.jsonl lo que escribiste, en ordenconfig.toml modelo y nivel de razonamientosession_index.jsonl cada hilo, una línea por cada unoskills/ las tuyas, más las propias del proyectoTres trampas en las que caímos para que las reconozcas
Cada una de ellas fue primero un defecto en Vobuda, y cada una dice algo cierto sobre los dos agentes.
El proceso más profundo de una sesión de Claude suele ser codex
Claude Code ejecuta Codex como su propio ayudante. Así que tomar el proceso más profundo del árbol para decidir a qué agente pertenece un bloque hacía que el dock dijera CODEX sobre una sesión de Claude, y que «nuevo» reiniciara el programa equivocado. El agente al que pertenece un bloque es el que la persona inició, no el que ese programa inició por su cuenta.
Codex no es node_repl
Codex se ejecuta como node, y una shell arranca un programa duplicándose a sí misma y luego reemplazándose por ese programa, así que la lista de procesos lo sigue llamando por el nombre antiguo el resto de su vida a menos que se pregunte por el ejecutable por su nombre. Un bloque que ejecutaba Codex solía titularse node_repl.
La lista de un agente sobre el bloque de otro agente
Dos listas de modelos y un flag de continuar se escribieron cuando había un solo agente, y siguieron siendo globales cuando ya había tres. Abrir un bloque de Codex ofrecía Opus, Sonnet, Haiku y Fable, y continuar enviaba codex --continue, a lo que Codex respondía con un error de uso. Ahora todo lo que se lee de un programa pertenece a ese programa y solo se le pide a él.
Las palabras del entorno de un agente cambian
Leer la respuesta de un agente, o la petición que se le dio, buscando palabras concretas en su interfaz falla en la siguiente versión de ese agente. En cambio, los dos se reconocen por forma: un agente se identifica por el prompt de espera que pone antes de lo que escribes, no por el recuadro dibujado alrededor, porque el recuadro es una moda y el prompt no.
La respuesta que la mayoría quiere de verdad es «los dos»
En la práctica nadie elige uno y borra el otro. Uno es mejor para lo que estás haciendo esta hora, el otro tiene la sesión donde estabas haciendo otra cosa, y los dos tienen límites de uso que llegan en momentos inoportunos. Lo que importa es si ejecutar los dos a la vez te cuesta algo.
En Vobuda no. Dos bloques en una pestaña, o dos pestañas, cada uno con su propia barra que lee a su propio agente, cada uno mostrando su propio modelo y esfuerzo, y el modo de permisos de Claude Code al lado. Los dos entregan sus señales a la ventana de la misma manera, así que una insignia, un sonido y un aviso significan lo mismo sin importar cuál de los dos los generó, y el registro de lo que pasó mientras estabas fuera los lista uno junto al otro, agrupados por bloque.
Ninguno se conecta mediante una sección de ajustes ni un interruptor, porque una señal que tienes que configurar antes de que funcione no es una función, es una tarea pendiente. Se conectan solos al arrancar, y el botón Integración de la tira de pestañas vuelve a poner los enlaces en un agente que ya estaba en marcha. Los hooks de terceros que ya existían se quedan donde están, y cualquier cosa que ya ocupara un evento se llama justo después de la nuestra.
Codex y Claude Code, sin rodeos
¿Qué es mejor, Codex o Claude Code?
En cuanto a calidad de código, es una pregunta sobre qué modelos ejecuta cada uno el día que preguntas, y cualquier respuesta escrita queda obsoleta. En cuanto a cómo se comportan como programas, Claude Code es el más legible desde fuera: escribe su lista de modelos en un archivo, guarda las sesiones en una carpeta por proyecto y usa un flag para retomar una. Codex mantiene más cosas internas.
¿Puedo ejecutar Codex y Claude Code a la vez?
Sí. Dos bloques en la misma ventana, cada uno con su propia barra de control que lee a su propio agente. Los dos avisan cuando terminan o necesitan permiso, y los dos aparecen en el mismo registro de lo que pasó mientras estabas fuera.
¿Cómo lista Vobuda los modelos de Codex?
Preguntándole a Codex. Una vez lanzamos una lista de dos modelos que Codex no ejecuta, y ya estaba mal el mismo día que salió. Ahora el botón de modelo abre el propio selector de Codex, lee las filas que muestra y pulsa la que elegiste, y cada modelo ofrece los niveles que Codex le da.
¿Alguno de los dos necesita una cuenta en Vobuda?
No. Vobuda no tiene cuentas de ningún tipo. Cada agente usa la suscripción o la clave que ya le diste. Vobuda usa el inicio de sesión de Claude Code para una sola cosa, preguntar a Anthropic por tus límites de uso, y nunca toca el de Codex.
¿Y un modelo local en su lugar?
Un modelo local a través de Ollama es una entrada en agents.json y no necesita código. Recibe un bloque y una barra con lo que ese agente pueda declarar honestamente sobre sí mismo.
Una ventana, los dos agentes
Gratis, sin cuenta, y cada barra lee al agente que tiene debajo.
curl -fsSL https://vobuda.com/install.sh | sh