Codex, atrapado entre la memoria y la cautela excesiva
CodexAI-агентыпамять агента
Qué está fallando realmente en Codex
No parece un único fallo, sino tres síntomas conectados: detalles inventados, instrucciones ignoradas y solicitudes interminables de confirmación. A 22 de agosto de 2026, la fuente primaria principal no es una nota de versión, sino un hilo de usuarios con quejas sobre un modelo llamado GPT-5.6-Sol.
El episodio más revelador trata de un pull request. El agente recibió una orden directa de crear y fusionar un PR. Lo creó, pero después pidió permiso por separado para hacer el merge. Tras recibir una confirmación normal, exigió además una frase de aprobación formulada de manera estricta.
Eso ya no es una comprobación útil antes de una acción irreversible. Es un bucle de aclaraciones en el que la interfaz de seguridad empieza a discutir con la intención claramente expresada por el usuario. Para un agente autónomo de programación, esa pérdida de iniciativa es crítica: la tarea avanza formalmente, pero el agente devuelve cada paso importante a la persona.
En el mismo hilo, los desarrolladores reportan fragmentos de lógica codificados de forma fija, incumplimiento de instrucciones y una posible reducción de límites. Este último punto sigue siendo una hipótesis de usuarios: el material disponible no contiene cifras confirmadas ni una explicación oficial del cambio.
Otro posible factor es la memoria local. La documentación de memoria de Codex describe almacenamiento basado en archivos en ~/.codex/memories/, incluidos memory_summary.md, MEMORY.md y raw_memories.md. Con el tiempo pueden acumularse resúmenes de sesiones y materiales relacionados con skills, por lo que limpiar el directorio es un paso diagnóstico razonable.
Sin embargo, no es una solución lista para usar. Un participante ya había eliminado memories y skills, y también probó una configuración limpia, sin resolver el problema. Esto indica que el origen podría estar más arriba: en las instrucciones del sistema, la política de confirmaciones o el comportamiento actual del modelo.
Por qué la cautela excesiva no equivale a fiabilidad
La consecuencia principal es sencilla: la autonomía desaparece justo donde más se necesita. Una confirmación adicional antes de borrar una base de datos puede estar justificada, pero renegociar un merge ya aprobado convierte una protección en un freno para el flujo de trabajo.
Primero separaría dos clases de fallos. Limpiar la memoria prueba el efecto del contexto acumulado; una sesión limpia ayuda a descartar skills locales y resúmenes antiguos. Si el bucle persiste, es más probable que el problema esté en la política general del agente que en un directorio de trabajo concreto.
La investigación sobre fallos de agentes describe modos similares como Operational Hallucination y Safety Drift: el agente repite acciones, pierde la restricción original o se comporta con excesiva cautela dentro de una tarea permitida. Esto no demuestra la causa de estas quejas concretas, pero explica bien el patrón observado.
Mientras no exista un registro oficial de un cambio de comportamiento, es prematuro hablar de un endurecimiento intencional de los guardrails. Aun así, la señal de ingeniería es preocupante: un agente que teme completar una operación autorizada puede ser más seguro sobre el papel y mucho menos controlable en el desarrollo real.