Codex /goal es real en la línea 0.128.0, pero antes de usarlo debes verificar tu versión instalada y la superficie de Codex en la que estás trabajando.
Al 4 de mayo de 2026, la documentación pública de OpenAI para CLI slash commands todavía no lista /goal; la evidencia más fuerte viene del release/source tree 0.128.0 y de las goal APIs experimentales de app-server.
Úsalo solo para un objetivo acotado con entregables, archivos, pruebas, presupuesto y regla de parada; si /goal no aparece o el objetivo no se puede auditar, empieza con /plan.
Respuesta rápida: /goal existe, pero depende de versión y superficie
/goal no es un prompt más largo. En Codex 0.128.0 sirve para fijar un objetivo de larga duración en el thread, de modo que el agente pueda seguir orientado a ese resultado durante continuation, pause, resume, budget limit y completion check. El release 0.128.0 menciona persisted /goal workflows, app-server APIs, model tools, runtime continuation y TUI controls para create, pause, resume y clear.
La parte delicada es que la disponibilidad no siempre aparece en todos los lugares a la vez. El 4 de mayo de 2026, la página pública de CLI slash commands mostraba /plan, /status, /resume, /compact, /ps, /stop y otros comandos, pero no /goal. La página de IDE slash commands tampoco lo presentaba como comando de IDE. Eso no vuelve falsa la función; obliga a separar release/source evidence, documentación pública, CLI local y pantalla actual.
Empieza con esta tabla:
| Lo que ves | Qué significa normalmente | Próximo paso |
|---|---|---|
codex --version muestra 0.128.0 o superior y el slash menu incluye /goal | Puedes probar el goal workflow | Empieza con un objetivo pequeño y auditable |
| Tu instalación está por debajo de 0.128.0 | El binary local puede no incluir la función | Actualiza y vuelve a revisar |
| La documentación no lo lista, pero tu CLI sí | La documentación puede ir detrás del release/source | Úsalo con claims fechados y verificación local |
| El IDE o app no lo muestra | La superficie no tiene por qué igualar al CLI | No copies instrucciones entre superficies sin revisar |
| No puedes escribir archivos, pruebas, evidencia y stop rule | El trabajo no está listo para /goal | Usa /plan primero |
En la máquina usada para comprobar el entorno local, codex --version devolvió codex-cli 0.125.0, así que no se podía asumir disponibilidad local. Esa es la situación real de muchos equipos: la función existe en una línea nueva, pero el terminal activo todavía no coincide.
Qué hace /goal según la evidencia de 0.128.0
La forma mínima observada en TUI es:
text/goal <objective>
El source de slash command describe Goal como una forma de "set or view the goal for a long-running task". También muestra que acepta inline args y que está disponible durante una tarea activa. Otro source de TUI devuelve Usage: /goal <objective> cuando no hay current goal y no se entrega texto de objetivo.
Por eso conviene no inventar gramática. No construyas procedimientos sobre /goal set, /goal audit o /goal complete salvo que tu versión instalada los exponga de forma explícita. La evidencia de 0.128.0 respalda la forma mínima y un lifecycle administrado por Codex, no subcomandos imaginados.
La mecánica se parece más a un contrato persistente de trabajo que a un simple "continúa":
- El thread conserva un objetivo actual.
- Runtime continuation puede seguir empujando hacia ese objetivo.
- Token accounting y wall-clock accounting participan en el presupuesto.
- Cuando se alcanza budget limit, Codex debe cerrar y resumir, no iniciar trabajo nuevo.
- App-server expone
thread/goal/set,thread/goal/getythread/goal/clear. - TUI tiene controles alrededor de create, pause, resume y clear.
La parte de seguridad también importa. El continuation template trata el objective como un dato de usuario no confiable y pide comprobar entregables concretos antes de marcar la meta como completa. El budget-limit template orienta a hacer wrap up. En otras palabras, /goal no significa "trabaja para siempre"; significa persistence, continuation, audit y budget stop.
Por qué puede faltar /goal
Si el comando no aparece, no empieces por trucos. Empieza por versión:
bashcodex --version
Si estás por debajo de codex-cli 0.128.0, el problema puede ser simplemente una instalación antigua. Actualiza Codex, reinicia la terminal o sesión si hace falta y vuelve al slash menu.
Después revisa la superficie. CLI, IDE, desktop app y app-server integration no son lo mismo. La documentación pública ayuda, pero la lista de comandos dentro del binary en ejecución decide lo que puedes escribir ahora.
El tercer límite es app-server. En el app-server API overview aparecen thread/goal/set, thread/goal/get y thread/goal/clear, marcados detrás de capabilities.experimentalApi. Eso confirma que "goal" es un concepto real de thread, pero no lo convierte en una API estable para todos los usuarios.
Secuencia práctica:
- Ejecuta
codex --version. - Abre el slash menu del CLI y busca
/goal. - Confirma si estás en CLI, IDE, app o app-server integration.
- Si no aparece, usa
/planpara volver el objetivo auditable y revisa tras actualizar. - Si necesitas APIs de goal en una integración, verifica primero la experimental capability.
La conclusión segura no es "la función no existe"; es "esta superficie no está confirmada".
Cómo escribir un objetivo útil para /goal
/goal solo ayuda cuando el objective es auditable. Un objetivo difuso permite que el agente se mueva durante mucho tiempo sin que puedas aceptar el resultado. Un objetivo útil define resultado, archivos, verificación, evidencia y condición de parada.
Usa esta estructura:
text/goal Implementar <resultado concreto> en <archivos o módulos>. Acceptance criteria: - User-visible behavior: <qué debe cambiar> - Files in scope: <rutas permitidas> - Verification: <tests, commands, screenshots, logs o revisión manual> - Evidence to report: <diff summary, test output, riesgos, pendientes> - Stop rule: <budget, falta de credencial, dependencia bloqueada, decisión ambigua>
Un objetivo débil:
text/goal mejorar el dashboard
Un objetivo usable:
text/goal Añadir export CSV a la billing usage table. Acceptance criteria: - Colocar la acción de export junto a los filtros existentes. - Limitar cambios a app/billing y shared CSV utilities. - El CSV incluye account id, period, model, tokens, cost y status. - Ejecutar npm test -- billing y npm run lint. - Detenerse si la billing API no expone raw row data.
La segunda versión le da a Codex espacio para trabajar sin inventar decisiones de producto. Si no puedes llegar a ese nivel, /plan va primero. Para dudas sobre login route, API key, suscripción o billing, usa Codex con API key o suscripción ChatGPT. Para presupuesto, ventanas y límites de ejecución, revisa OpenAI Codex usage limits. Si el problema es configuración local, ve a Codex config.toml.
Flujo seguro para tareas largas
El flujo sano es plan, set, monitor, verify y clear or continue. Los nombres de botones pueden cambiar por superficie, pero el modelo de control no debería cambiar.
| Etapa | Qué hacer | Evidencia necesaria |
|---|---|---|
| Plan | Convertir el pedido en scope, acceptance criteria, verification y stop rules | Objective text y notas de alcance |
| Set | Usar /goal <objective> solo cuando el objetivo ya es auditable | Versión, command surface y registro del objetivo |
| Monitor | Observar active, paused, resumed, budget-limited | Progress notes, changed files, command output |
| Verify | Comparar el resultado con entregables concretos | Tests, screenshots, logs, diff summary |
| Clear or continue | Limpiar la meta al terminar o revisar el objective | Remaining risks y next action |
El fallo más peligroso es aceptar un transcript largo como prueba. Antes de cerrar, revisa:
- Los archivos modificados siguen dentro del scope?
- Se ejecutaron los tests prometidos o se explicó por qué no?
- Hay artifacts reales, no solo una explicación segura?
- Se evitaron refactors sin relación y decisiones de producto escondidas?
- Un estado budget-limited cerró el trabajo en vez de abrir uno nuevo?
- Hay razón clara para continuar o conviene limpiar la meta?
Si una respuesta es débil, el trabajo no está completo. Pide evidencia, ajusta el objective o detén la ejecución. /goal mejora continuidad, no reduce la exigencia de review.
Cuándo no usar /goal
No empieces con /goal si el problema todavía es ambiguo. No es la herramienta adecuada para brainstorming amplio, exploración sin success condition, trabajo que necesita production access no concedido, tareas caras sin budget o cambios que no sabrás verificar.
Evítalo cuando:
- faltan credenciales, permisos de producción o decisiones de política;
- el scope cruza demasiados módulos para revisar bien;
- no puedes escribir una stop rule;
- no sabes cómo reconocer completion;
- intentas compensar un prompt débil con más horas de agente.
Para tareas pequeñas basta un prompt normal. Para descomponer, usa /plan. Para continuidad de conversación, mira /resume o /compact. /goal encaja cuando el trabajo es lo bastante grande para necesitar persistence y lo bastante concreto para auditarse.
Para comparar modelos de trabajo entre agentes, revisa Claude Code vs Codex. La pregunta aquí no es quién parece más autónomo, sino quién puede demostrar que el estado final coincide con los criterios.
Preguntas frecuentes
¿Codex /goal está disponible?
Existe en la evidencia release/source de 0.128.0 comprobada el 4 de mayo de 2026. Aun así, las páginas públicas de CLI e IDE commands iban por detrás, así que revisa versión y command surface local.
¿Cuál es la sintaxis?
La forma mínima confiable es /goal <objective>. No asumas subcomandos extra si tu versión instalada no los muestra.
¿Por qué mi CLI no tiene /goal?
Las causas más comunes son versión antigua, superficie diferente o documentación atrasada. Comprueba codex --version, actualiza y mira el slash menu del CLI.
¿/goal reemplaza a /plan?
No. /plan sirve para dar forma al trabajo. /goal sirve cuando el objetivo ya es concreto y auditable.
¿Puedo dejar /goal trabajando toda la noche?
No como modo predeterminado. Necesitas budget, acceptance criteria, file scope y evidencia revisable. Un budget-limited wrap-up no equivale a éxito.
¿Conviene usar goal APIs de app-server?
Solo si estás construyendo deliberadamente contra la superficie experimental de app-server y verificaste capabilities.experimentalApi. Para uso normal, empieza por el CLI.