Does the non-interactive mode of Codex support goals?

[duguyue8]

Does the non-interactive mode of Codex support goals?

[etraut-openai]

Yes, you can have the agent to create a goal for itself using a prompt like codex exec "Create a goal to implement my_app.spec".

[krishkhinchi]

I don’t think goals are officially supported in non-interactive mode yet, at least not from the current docs for codex exec. The docs mainly describe one-shot task execution. ([Mintlify]1)

That said, /goal itself does exist as an experimental feature in newer Codex CLI versions and is aimed at long-running workflows. ([Reddit]2)

So right now it seems more tied to interactive sessions/TUI flows rather than codex exec automation mode.

---

If this answer solve your all doubts so can you please mark this answer as solved
or if did not solved yet so please tell me your doubt

[developerisnow]

Thanks for the clarification above. I ran a few more experiments with codex exec goals and wanted to share the observed behavior. This is not meant as a complaint; I am trying to understand what the intended contract is for non-interactive usage, especially for wrappers that run codex exec --json resume <thread> -.

Environment:

• codex-cli 0.130.0
• features.goals = true in ~/.codex/config.toml
• main flow is a Telegram wrapper around codex exec --json --skip-git-repo-check resume <thread> -
• I inspected ~/.codex/state_5.sqlite.thread_goals to verify persisted goal state

Experiment 1: natural-language goal request in a resumed exec thread

Prompt shape was roughly:

Create a goal to Build the Meta0 LifeOS ontology boundary artifact...

Observed result:

• The agent produced a proposed /goal ... text / plan, but did not call the goal tool.
• get_goal later returned null.
• No row existed in thread_goals for that thread.
• The work could still be done normally as a regular codex exec task, but there was no formal active goal.

So the earlier wording codex exec "Create a goal ..." seems model-mediated rather than deterministic. It can work, but the agent may interpret it as “write a goal command/proposal” rather than “call create_goal”.

Experiment 2: explicit tool-style wording in the same resumed exec thread

I then used stricter wording:

Create a goal for this thread using the goal tool, not as prose.

Objective:
Build the Meta0 LifeOS ontology boundary artifact...

After creating it:
1. call get_goal
2. if get_goal is null, stop and print GOAL_NOT_CREATED
3. if get_goal.status is active, print GOAL_CREATED with goal_id and objective
4. do not start implementation until goal is confirmed active

Observed result:

• This time the agent did call create_goal.
• Then it called get_goal, which returned status: active.
• It printed GOAL_CREATED and the exec turn ended.
• A row appeared in thread_goals.

This part worked.

One small confusing detail: the create/get tool output visible in the transcript included threadId, objective, status, tokens/time, but I did not see the actual goal_id in the tool output. The SQLite row does contain a separate goal_id. The agent printed the thread id as goal_id, which is not quite correct.

Experiment 3: what happens after creation

Immediately after the GOAL_CREATED turn, the JSONL showed an injected continuation-style message:

Continue working toward the active thread goal.
...
Before deciding that the goal is achieved, perform a completion audit...
If the objective is achieved, call update_goal with status "complete"...

But the next record was:

<turn_aborted>
The user interrupted the previous turn on purpose...
</turn_aborted>

The persisted goal became paused.

After I sent a second explicit continuation prompt:

Continue working toward the existing thread goal. Do not create or replace the goal.
First call get_goal and report status. If the goal is paused, continue/resume work toward it. Perform the completion audit...

Observed result:

• get_goal initially showed status=paused.
• The agent continued the audit anyway.
• It concluded the objective was already achieved.
• It called update_goal(status="complete").
• SQLite now shows the goal as complete.

This also worked, but it required a second turn and fairly explicit instructions.

Experiment 4: fresh smoke thread

A separate smoke test in a fresh codex exec thread also successfully created and completed a persistent goal. That suggests the goal tools themselves work in non-interactive mode, but activation is not currently a deterministic CLI/API contract from the operator perspective.

Questions

1. Is codex exec "Create a goal ..." intended to reliably invoke the goal tool, or is it intentionally just natural language that the model may or may not turn into create_goal?

2. Is there, or should there be, a first-class non-interactive command/API for this, for example something like codex exec --goal ..., codex goal set/get/resume/clear, or an app-server endpoint intended for headless wrappers?

3. For codex exec --json, should goal lifecycle changes be emitted as structured JSON events? Today I can inspect SQLite, but I did not see a clean goal_created, goal_paused, goal_completed event in the --json stream.

4. Is reading ~/.codex/state_5.sqlite.thread_goals an acceptable operator workaround, or is that considered private/internal and likely to break?

5. When a goal is created in a non-interactive exec turn, is the process supposed to continue working toward it automatically, or is the expected pattern two-phase: first create/verify goal, then send a second Continue working toward the active goal... prompt?

6. In the paused case, what is the intended non-interactive way to resume/unpause a goal? In TUI there is /goal resume, but for exec I only found natural-language prompting.

7. Should the create_goal / get_goal tool result expose the actual goal_id, not only threadId, so wrappers can report the correct identifier?

Current practical workaround

For now, the reliable wrapper pattern seems to be:

Create a goal for this thread using the goal tool, not as prose.
After creating it, call get_goal.
If get_goal is null, print GOAL_NOT_CREATED and stop.
If active, print GOAL_CREATED and stop.

Then a second turn:

Continue working toward the existing thread goal.
Call get_goal first.
If complete, call update_goal(status="complete").
If not complete, continue the work and only call update_goal when the audit passes.

This is workable, but fairly brittle for automation. I would love to know whether this is the intended design for codex exec, or if there is a better supported path that wrappers should use.

[developerisnow]

One additional lifecycle edge case I hit after the comment above:

After the goal in a resumed codex exec thread was marked complete, I tried to create a new goal in the same thread using the explicit "use the goal tool, not prose" prompt.

Observed:
GOAL_NOT_CREATED
reason: goal tool refused creation because this thread already has an existing goal.
existing_goal_status: complete
existing_goal_id: <thread_id>

So a completed goal still appears to block creating the next goal in the same thread.

Questions:

1. Is a Codex thread intended to have at most one goal forever, even after complete?
2. In non-interactive codex exec, what is the supported way to clear/replace a completed goal?
3. Should complete make the thread eligible for a new goal, or should wrappers always start a fresh thread for a new goal?
4. The reported existing_goal_id looked like the thread id, while SQLite has a separate goal_id. Is that expected?

[etraut-openai]

Answers to your questions:

1. The request needs to be pretty explicit to have the model create a goal. We don't want it creating a goal by mistake when that's not the user intent. Your experiment 2 is a good example of an explicit prompt.
2. There is currently not a first-class command for this. It's an experimental feature currently, and it's still being refined and debugged. I would want to wait for the feature to become stable and see if there's sufficient community demand before we add a dedicated command.
3. That could be a future enhancement if there's sufficient user demand.
4. The state database is considered a private implementation detail. You shouldn't count on it. We've changed it in the past, and I can guarantee that we'll change it in the future.
5. The thread should work toward the goal as soon as it is created (assuming it's created in the active state). If that's not what you're seeing, please file a bug report with repro steps.
6. There is no way to unpause a goal in the non-interactive state. I wouldn't expect there to be a need to pause or unpause for non-interactive sessions.
7. The goal ID is an internal implementation detail and should not be exposed. There can be at most only one goal associated with a thread, so there's no need to distinguish between different goals.

It looks like you may be using goal in a way that's a little outside of its target use cases. That's fine, but it means that you will likely hit some impedance mismatches. We can consider addressing some of these gaps over time if there is sufficient user demand.

In the meantime, if you're using non-interactive mode, it's easy to script an external loop that effectively does what goal does. You can then apply whatever continuation and reporting semantics that you'd like for your use case.