Codex CLI Goal: Define Work and Know When to Stop

A Codex CLI goal is the task description you give the agent at the start of a session. It shapes what the agent tries, how it decides when it is done, and what it does when it gets stuck. A vague goal produces uncertain work; a specific goal with clear completion criteria produces a result you can check.

The goal you write in the terminal lasts only for that session. Tools like fenbs keep the task plan, the approved approach, and the progress note outside the session, so any session, on any model, can continue the same work without needing you to re-explain it.

What makes a goal specific enough

A useful goal says what to do, what to leave alone, and what a finished result looks like. It does not need to be long. Three sentences can be enough: the thing to change, the boundary of the change, and the check that proves it worked.

Say a design studio needs to update the pricing page. A vague goal: "Fix the pricing page." A specific goal: "Update the pricing page to replace the three-column layout with a two-column layout. Leave the copy unchanged. The page should render correctly at 375px and 1280px widths with no overflow."

The specific version tells the agent what is in scope (the layout), what is out of scope (the copy), and what done looks like (renders at two widths with no overflow). The agent can check the criteria without asking.

Set a scope boundary

A scope boundary is an explicit instruction about what the agent should not change. Without one, the agent may decide that a nearby improvement is also relevant and make a change you did not ask for.

• Name the files or directories in scope: "only in src/components/Pricing".
• Name things that are out of scope: "do not change any test files; do not update the copy in the pricing page".
• Describe the kind of change: "refactor only, no new dependencies; fix only, do not add features".

For standing rules that apply to many sessions, record them in a shared tool like fenbs as Decisions and rules. A connected assistant reads them before it starts, so you do not have to repeat the constraints each time. The codex cli best practices guide covers this in more depth.

State your completion criteria

Completion criteria tell the agent when it should stop and report back rather than continuing. Without them, the agent may decide that any related improvement is part of the task.

Good criteria are checkable: a test passes, a file no longer contains a pattern, a build succeeds, an output matches a format. Criteria like "the code looks good" or "the feature works" are hard for the agent to evaluate consistently.

If the criteria involve a check the agent cannot run, say so: "The endpoint change is done when the file is updated and the unit tests pass. I will confirm the integration test manually." This separates what the agent can verify from what needs a human check.

Interrupt and resume a session

Press Ctrl+C to interrupt a running Codex CLI session. The agent stops at the current step. File changes already made are not automatically rolled back; you can review them with git diff and revert if needed.

If you interrupt because the agent went in the wrong direction, clarify the goal before restarting. Add the correction to your task record so the next session starts with the refined version, not the original that produced the wrong result.

If you need to undo changes the agent made before you interrupted, see the codex cli undo guide for how to use Git to recover the previous state.

Check progress during a long task

For tasks that run for several minutes, you can ask the agent to report its current status without stopping the session. In interactive mode, you can type a message while it works. The agent describes what it has done and what remains, then continues.

For longer automated runs, a post-step hook can log progress to a file you can read without interrupting the agent. See the codex cli hooks guide for how to set these up.

Pass the work on when a run stops

When a session ends, whether it finished, was interrupted, or hit an error, record where it stopped before you close the terminal. A progress note should say what the agent completed, what it checked, and what the next step is. Without that note, the next session has to rediscover the state from the files.

Keeping that note in a shared place means any session can continue the task, not just the next one you open on the same machine. In fenbs, Where we left off on a task holds exactly this: the plan, the current status, and the next step.

How to do this with fenbs

1. Create a free account and add the task to your project. Write the goal, scope, and completion criteria as the task plan.
2. Add any standing constraints as Decisions and rules in the project, not in the task plan. Rules apply to every session; task details apply only to this one.
3. Connect Codex CLI to fenbs from Integrations and ask it to read the task plan and project rules before it starts.
4. When a session ends, ask Codex CLI to update Where we left off: what it completed, what it checked, and the next step.
5. Before starting a new session, read the Where we left off note and confirm the goal still reflects what you want before the agent begins.

For tasks that run in parallel across branches, the codex cli worktree guide explains how to keep each goal isolated in its own directory.