Add first-class programmatic goal creation for codex exec

What variant of Codex are you using?

CLI, specifically codex exec / headless automation.

What feature would you like to see?

Please add a first-class, deterministic way to create or set a thread goal from the CLI or another program, without relying on the model to interpret a prompt that happens to begin with /goal.

Today, an interactive TUI user can type:

/goal write 10 files with funny poems

and the TUI slash-command path sets the thread goal directly. In codex exec, however, a command like this:

codex exec "/goal write 10 files with funny poems"

is just sent as ordinary user text for the model turn. It may appear to work if the model infers the user's intent and uses goal tools, but that is model-mediated behavior, not deterministic slash-command dispatch or a control-plane API exposed by codex exec.

The feature request is for one of these equivalent CLI surfaces:

codex exec --goal "write 10 files with funny poems"
codex exec goal "write 10 files with funny poems"
codex exec resume --set-goal "write 10 files with funny poems" <thread-id>

Expected behavior:

1. Validate that goals are enabled and the target thread supports persisted goals.
2. Set the objective through the existing app-server goal control plane, e.g. thread/goal/set.
3. Start or continue the associated turn with clear semantics that do not depend on model interpretation of a slash command.
4. Work in --json mode so wrappers can observe thread id, goal status, turn progress, completion, blocked state, and token-budget accounting.
5. Reject unsupported cases clearly, such as ephemeral threads if persisted goals are required.

It may also be useful for codex exec to dispatch leading /goal <objective> for parity with the TUI, but an explicit flag/subcommand would be less surprising for scripts and avoids treating arbitrary prompt text as a command.

Additional information

I hit this while testing whether codex exec "/goal ..." really triggers Goal mode. The observed behavior can be confusing because the task may still succeed, but the mechanism is not the same as the interactive /goal slash command.

From inspecting the current source on main:

• The interactive UI has a SlashCommand::Goal path.
• codex exec resolves the positional prompt and sends it as UserInput::Text.
• The app-server protocol already has goal RPCs such as thread/goal/set / thread/goal/get / thread/goal/clear.
• I could not find a documented or deterministic codex exec flag/subcommand that exposes goal creation directly.

Why this matters:

• Automation cannot reliably start durable goal work without either using the interactive TUI or asking the model to infer that /goal ... should become a goal.
• Supervisors and wrappers need goal creation to be a control-plane operation, not a natural-language convention.
• This is adjacent to long-running/headless workflows where goals are durable work items and codex exec --json is the natural integration point.

Related issues:

• #24016 asks for promptless/follow resume behavior once an active goal already exists.
• #24094 covers goal-management tool exposure to the model.
• #25565 covers generated Python app-server protocol types for goal RPCs.

This issue is specifically about starting or setting a goal from the headless CLI/programmatic surface.