Skip to content

fix(codex): el config que no abría, y un perfil por modelo - #27

Open
borjaperfra wants to merge 2 commits into
mainfrom
fix/codex-duplicate-key-y-perfiles
Open

borjaperfra wants to merge 2 commits into
mainfrom
fix/codex-duplicate-key-y-perfiles

Conversation

@borjaperfra

Copy link
Copy Markdown
Contributor

La #24 arregló el wire_api para quien configurase Codex desde cero y dejó fuera justo al que ya estaba roto.

El fallo

writeCodexConfig salía antes en cuanto veía api.nan.builders: corregía el wire_api y retornaba, sin llegar nunca a withCodexContextWindow. Un miembro que hubiera pasado el setup dos veces tenía dos model_context_window al final del fichero, y eso es una clave duplicada:

C:\Users\...\.codex\config.toml:82:1: duplicate key

Con eso Codex no carga nada. La CLI sale con el error y la app de escritorio abre un diálogo failed to read configuration layers y se cierra. Actualizar y volver a pasar por Setup le cambiaba el wire_api y lo dejaba igual de atascado.

Al final del fichero la clave tampoco era una clave raíz: caía dentro del último [projects.*] confiado, donde Codex no la lee.

El arreglo

Poda antes de reparar. Una model_context_window dentro de una tabla con nuestro valor es nuestra y se va; con otro valor se queda. En la raíz sobrevive la primera. Después se repone encima del primer header. Desconectar Codex se lleva también la clave, que sin la sección no significa nada.

Probado contra el config.toml real de un miembro al que la app no abría: queda una sola clave, en la raíz, y Codex arranca.

Y los modelos

codex --model <id> cambia el modelo pero no la ventana, así que un modelo de 262.144 corre con el millón que declaramos y Codex compacta contra una ventana que no existe.

Codex 0.155 superpone $CODEX_HOME/<nombre>.config.toml sobre el config base, y ahí sí cabe una ventana por modelo. Se escribe uno por modelo de chat, sin la key dentro. El nombre no puede ser el id — Codex pide "a plain name" y rechaza el punto — así que van sin puntos y con prefijo nan-, que es lo que permite retirarlos sin tocar los del miembro.

codex -p nan-glm53-flash
codex -p nan-qwen36

Comprobado

  • go build ./... y go test ./... en verde; gofmt no señala ninguno de los dos ficheros.
  • 7 tests nuevos, sobre los 5 de Codex que ya había.
  • Contra Codex 0.155.0-alpha.9.2 de verdad: el config rescatado arranca, y -p nan-qwen36 da model: qwen3.6, provider: nan.

Queda fuera

  • El OutputTextDelta without active item sigue: es el streaming del backend que la fix(codex): dejar de escribir el wire_api que ya no arranca #24 ya dejó anotado.
  • Al miembro cuyo Codex no abre hay que decirle que el arreglo está aquí. codex doctor lo detecta (✗ config could not be loaded) y arranca aunque el config no cargue, pero la TUI no mira el fichero al abrir. Lo dejo para decidir aparte.

🤖 Generated with Claude Code

borjaperfra and others added 2 commits September 19, 2026 16:13
Dos pasadas del setup dejaban dos model_context_window al final del
fichero. Dos son una clave duplicada y Codex no carga el fichero: la CLI
sale con el error y la app de escritorio abre un diálogo y nada más. Y
al final del fichero la clave no es una clave raíz, sino una del último
[projects.*] que el miembro haya confiado, donde Codex no la lee.

La reparación de la #24 no alcanzaba a ese miembro. writeCodexConfig
salía antes en cuanto veía api.nan.builders: le corregía el wire_api y
lo dejaba igual de atascado, con el duplicate key intacto. Ahora poda
primero y repone la clave encima del primer header. Una dentro de una
tabla con nuestro valor es nuestra y se va; con otro valor se queda,
que no es nuestra. En la raíz sobrevive la primera.

Desconectar Codex se lleva también esa clave. Antes quedaba huérfana,
nombrando una ventana que ya no sirve a ningún modelo del miembro, y si
eran dos quedaba un fichero que no abre y ya sin nada que dijera quién
lo había escrito.

Probado contra el config.toml real de un miembro al que la app no le
abría: queda una sola clave, en la raíz, y Codex arranca.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`codex --model <id>` cambia el modelo y nada más: la
model_context_window del config.toml se queda donde estaba, así que un
modelo servido a 262.144 corre con el millón que declaramos nosotros y
Codex compacta contra una ventana que no existe. Es el mismo fallo que
tenía Pi al revés, y con un solo fichero no tiene arreglo.

Codex 0.155 superpone $CODEX_HOME/<nombre>.config.toml sobre el config
base, que es el único sitio donde una ventana puede viajar con su
modelo sin duplicar el proveedor, los MCP y los permisos del miembro.
Escribimos uno por modelo de chat del catálogo.

El nombre no puede ser el id: Codex pide "a plain name" y rechaza el
punto, así que glm5.3-flash no vale como perfil aunque sí como modelo.
Van con los puntos fuera y el prefijo nan-, que es lo que los hace
nuestros para poder retirarlos después sin tocar los del miembro.

Sin la key dentro: la lleva el proveedor del config base, y una key en
ocho ficheros son ocho ficheros que rotar.

Probado contra Codex 0.155: `codex -p nan-qwen36` arranca con qwen3.6 y
el proveedor nan.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants