Un asistente de programación puede seguir trabajando sobre una comprobación fallida, pero la prueba y el código final necesitan tu revisión. Esta guía es para quien mantiene un repositorio con un comando de prueba, compilación o análisis de estilo que ya falla. Usa un Goal acotado en Claude Code o, como opción separada, la CLI interactiva de Codex. Elige una. La meta es que el comando original pase con un cambio revisado que conserve el comportamiento fijado de antemano. Si no puede demostrarse, conserva el fallo y el bloqueo exacto. Es un procedimiento basado en documentación: BIG CHANGE no ejecutó un Goal ni reparó un repositorio para este artículo.

El gran cambio

  • Qué cambió: Los comandos documentados /goal mantienen un objetivo activo entre turnos, de modo que el asistente puede investigar un fallo, hacer un cambio acotado y volver a comprobar sin una instrucción nueva en cada turno.
  • Por qué importa: Puedes definir el comando original, los archivos permitidos y el comportamiento protegido antes de iniciar el ciclo. Así los intentos mantienen el mismo criterio de aceptación.
  • Qué vigilar: Un estado Goal o un veredicto del modelo no demuestra la reparación. Lee la salida real y el diff final y decide tú si aceptas el cambio.

Antes de empezar: registra el fallo y los límites

Usa un repositorio que puedas modificar con autorización. Lee las instrucciones locales, incluidos AGENTS.md o CLAUDE.md si existen, y comprueba la rama, las modificaciones previas y los archivos sin seguimiento. En Git estos comandos dan un inventario inicial:

Terminal
git status --short
git diff --stat
git diff

Guarda ese inventario para distinguir los cambios del asistente del trabajo previo. Ejecuta la comprobación real que falla una vez o conserva una ejecución reciente fiable con el comando exacto, error completo y estado de salida. No la sustituyas por un ejemplo del artículo. Registra antes cualquier dependencia de un servicio, secreto o plataforma inaccesible. Un único cambio conocido puede resolverse mejor con una petición normal; un Goal sirve cuando cada resultado determina el siguiente diagnóstico.

Escribe fuera del Goal una nota breve de aceptación: comando exacto, resultado actual, rutas y herramientas permitidas, comportamientos y pruebas que deben conservarse y decisiones que requieren detenerse para revisar. Protege expresamente los cambios previos sin relación. No dejes que el asistente borre o debilite la prueba para fabricar un éxito. Revisa la nota antes de autorizar herramientas. Pedir una parada tras cierto número de turnos puede orientar al modelo, pero no garantiza un límite de gasto.

1. Elige una sola interfaz Goal

En Claude Code, abre la sesión del repositorio previsto y comprueba que /goal esté disponible. Su manual de Goal, revisado el 20 de octubre de 2026, dice que depende de la confianza del espacio de trabajo y de los ajustes de hooks. Solo puede haber un Goal activo por sesión. Una condición nueva sustituye a la anterior y empieza inmediatamente. El Goal no cambia el modo de permisos: el modo manual puede seguir pidiendo permiso antes de usar herramientas; el modo automático es otro ajuste. Mantén tus controles habituales de archivos, comandos y red.

Para la alternativa de la CLI interactiva de Codex, comprueba la versión instalada y la lista de comandos con barra. El recetario de Goals de OpenAI sitúa su inicio en Codex 0.128.0. Su guía de uso documenta un ajuste features.goals si falta el comando. Son comprobaciones para tu instalación; no se ejecutaron para este artículo:

Terminal
codex --version
codex features enable goals

Activa la función solo si tu instalación lo necesita y tu organización lo permite. Estas instrucciones de Codex corresponden a la CLI interactiva. No presupongas el mismo soporte en codex exec ni en todas las versiones de escritorio. Si sigue faltando el comando, detente y revisa versión, ajuste y acceso de la cuenta o espacio de trabajo antes de elegir otro método.

2. Define la condición acotada

Usa /goal seguido de la condición revisada. Incluye el comando real y las rutas permitidas; no pegues un nombre de prueba inventado. Por ejemplo: «Haz que pase mi comprobación ya fallida usando solo las rutas y herramientas de mi nota de aceptación. Tras cada intento, muestra el comando, el resultado completo y los archivos cambiados. Conserva el comportamiento protegido y los cambios ajenos. Si la comprobación no puede ejecutarse o no queda un cambio seguro dentro del alcance, detente con el error exacto, los cambios intentados y lo que necesitas de mí». Sustituye «mi comprobación» por el comando exacto y adjunta o señala la nota revisada antes de empezar.

Ambos comandos documentados /goal aceptan una condición no vacía de hasta 4.000 caracteres. Mantén las restricciones detalladas en la nota. En Claude Code, /goal <condition> inicia un turno inmediatamente. En la CLI interactiva de Codex, /goal <objective> asocia un objetivo persistente al chat actual. Ninguna vía concede nueva autoridad sobre archivos, comandos o cuentas. Si la reparación exige más rutas, un servicio externo, un secreto, una fusión o un despliegue, pausa para una decisión del responsable.

3. Observa las pruebas mientras trabaja

Pide la salida exacta después de cada intento significativo y una lista de archivos cambiados. Ejecuta /goal sin argumento para ver el estado. Claude Code muestra tiempo transcurrido, turnos evaluados, consumo de tokens y el motivo más reciente del evaluador tras evaluar. El evaluador lee lo que Claude mostró en la conversación; no ejecuta por su cuenta la prueba ni inspecciona archivos. Un veredicto «met» pide verificación, no demuestra la reparación. El estado Goal de Codex también necesita la salida del comando y el diff como evidencia.

Mantén el ciclo en el alcance original. Lee los comandos antes de autorizarlos, sobre todo si borran archivos, reescriben historial, envían datos fuera o cambian permisos. Detente si se debilitó la prueba original, cambió un archivo ajeno sin explicación o se expondrían datos privados. Si no puedes autorizar con seguridad lo siguiente, registra el estado Goal y pide un plan más limitado.

4. Verifica el resultado tú mismo

Cuando el asistente anuncie éxito, inspecciona el diff final completo frente al inventario inicial. Comprueba cada archivo modificado o creado contra las rutas permitidas. Ejecuta el mismo comando original de comprobación otra vez si es viable y guarda la salida completa y el estado de salida. Ejecuta las pruebas pertinentes sin modificar de tu nota y revisa el comportamiento que debía preservarse. Que pase una prueba sustitutiva no cumple el acuerdo.

Acepta el cambio solo si la evidencia coincide con la condición revisada y apruebas el diff. Mantén commit, fusión y despliegue como decisiones autorizadas por separado. Si falla la verificación, conserva comando y salida exactos, archivos modificados, estado Goal y el permiso, dependencia o decisión que falta. Un Goal pausado, interrumpido, imposible, bloqueado o limitado por presupuesto no es una reparación terminada.

Si el Goal se detiene o atasca

En Claude Code, /goal muestra la condición y el motivo más reciente; /goal clear elimina el Goal activo. Su manual dice que una condición activa puede restaurarse al reanudar una sesión, aunque se reinician las bases de tiempo, turnos y tokens. La restauración desde el selector de sesiones se corrigió en v2.1.239. Los fallos de autenticación gestionada por Claude Code, crédito agotado, desbordamiento irrecuperable del contexto y modelo no disponible pueden borrar el Goal. La autenticación gestionada por el anfitrión puede dejarlo activo. Otros errores pueden conservarlo y reintentar o pausar; los avisos interactivos se documentan para v2.1.269 o posteriores. Lee el aviso, estado, salida guardada y diff antes de fijar o reanudar nada. Una condición nueva sustituye la anterior.

En la CLI interactiva de Codex, /goal muestra el objetivo, mientras /goal edit, /goal pause, /goal resume y /goal clear son controles documentados en la referencia de comandos CLI. Su recetario distingue la finalización de una pausa, interrupción, límite de presupuesto o bloqueo. Inspecciona el estado y las pruebas reales del repositorio antes de reanudar o cambiar el objetivo. Si un límite de presupuesto o acceso detuvo el trabajo, puede ser más útil registrar un bloqueo preciso que hacer otro intento.

Los turnos usan cuota o créditos de la cuenta y el evaluador separado de Claude Code también consume tokens. Revisa tus controles y límites actuales. Una cláusula de tiempo o turnos en prosa no garantiza un techo en dólares. Usa solo material autorizado del repositorio, excluye secretos y archivos privados ajenos, y examina las instrucciones encontradas antes de que el asistente las siga.

Para una tarea de configuración distinta, nuestra guía del entorno Codex Cloud cubre conectar y preparar un repositorio remoto. Nuestra guía de Team Tasks compartidas trata el trabajo recurrente en ChatGPT. Ninguna configuración es necesaria para el procedimiento local anterior.

Fuentes y lecturas complementarias