Skip to content

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

Merged
borjaperfra merged 3 commits into
mainfrom
fix/codex-duplicate-key-y-perfiles
Sep 21, 2026
Merged

borjaperfra merged 3 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>
Tres cosas que salieron al revisar este PR.

La ventana que este CLI escribe hoy va en la tabla raiz, encima del primer
header, y la poda solo se llevaba de la raiz los repetidos: la primera
siempre sobrevivia. Conectar en una maquina limpia y desconectar dejaba
model_context_window = 1048576 en el fichero, una ventana para un modelo que
el miembro ya no tiene. Los tests de borrado usaban todos la forma que dejaba
el bug viejo - la clave dentro de un [projects.*] - asi que la que el CLI
escribe de verdad nunca paso por ahi. codexContextWindowsCleared es esa
mitad; la del arreglo se queda como estaba.

Los perfiles se borraban al final de removeCodexConfig, detras de los dos
returns tempranos. Quien hubiera editado a mano nuestra seccion, o borrado el
config, se quedaba los siete nan-*.config.toml, cada uno apuntando a un
model_provider = "nan" que ya no resuelve: codex -p nan-qwen36 falla y ningun
tool de la maquina reconoce haberlos puesto. Ahora se borran los primeros,
porque existen aparte de lo que diga config.toml. Su error se guarda para el
final: un perfil que no se deja borrar es un fallo cosmetico, y devolverlo
antes dejaba el experimental_bearer_token dentro del config justo despues de
que alguien pidiera quitarlo.

Y la poda dentro de tablas miraba solo el valor. 1048576 es el numero que
publicamos para GLM 5.3 Flash, o sea el que es mas probable que el miembro
haya escrito el mismo - y este PR le ensena a escribirlo en un [profiles.*].
Su ventana desaparecia del perfil y reaparecia en la raiz, cambiando en
silencio lo que ese perfil hace. Ahora solo se poda bajo [projects.*], que es
la unica forma que el bug de anadir al final podia producir.

Queda fuera: la reparacion sigue reconociendo solo la ventana del modelo de
coding actual, asi que el dia que ese numero se mueva dejara de reconocer las
claves que escribio este mismo CLI. Y el prefijo nan- sigue pudiendo pisar un
nan-loquesea.config.toml del miembro.

5 tests nuevos, cada uno comprobado mutando el arreglo que cubre.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@borjaperfra
borjaperfra merged commit 02f39c1 into main Sep 21, 2026
5 checks passed
@borjaperfra
borjaperfra deleted the fix/codex-duplicate-key-y-perfiles branch September 21, 2026 17:16
@borjaperfra borjaperfra mentioned this pull request Sep 21, 2026
borjaperfra added a commit that referenced this pull request Sep 21, 2026
Entrega lo mergeado desde la 0.1.20:

- #25 el enlace de login dice que vence, y fuera la pantalla que ya no se
  dibujaba
- #27 el config.toml que Codex no abria, y un perfil por modelo con su
  ventana
- #29 el tablero recoge tambien los PR de fuera
- #30 como salir del prompt del enlace, y un test que no dependa del ancho
  del terminal

Primer release que sale por si solo: desde la #28 el tag lo crea tag.yml al
pasar CI en main, leyendo esta constante.
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