Goals

A goal is a condition a terminal keeps working toward. After each run, a separate check reads the checkout and decides whether the condition holds. If it does not yet, the terminal gets a follow up and carries on.

The command

Type it in a terminal’s input box like any prompt.

/goal all tests pass

/goal is the only command a terminal accepts. Anything else that starts with a slash is refused with only /goal is available here. It is never sent to a provider, and your text stays in the box so you can edit it. A path at the start of a prompt, like /src/app.ts is broken, is not a command.

The typed /goal is colored wherever the prompt shows, in the keyword color of your code theme, so you can see the terminal recognized it.

You can also ask the orchestrator for a goal in plain words, for example “make it a goal for Terminal 2 that the build is green”. The task it plans is written as the command, so the row you confirm shows exactly what the terminal will receive. Typing /goal on the phone works the same way.

The loop

1. The transcript shows Goal set with the condition, and the run starts. The agent is told the goal and that a separate check follows each turn.
2. When the run finishes cleanly, the check runs on your fallback model, set in Settings > AI Providers. It runs read only in the terminal’s own checkout. It sees the condition and the agent’s last reply, and it treats the agent saying the goal is met as a claim to verify, not as proof. The terminal shows the Working shimmer while it runs.
3. If the condition holds, the transcript shows Goal met and the goal ends.
4. If the check finds the goal cannot be reached without you, the transcript shows Goal blocked with the reason, and the goal ends.
5. If the condition does not hold yet, the terminal gets a follow up on the same conversation that says what is still missing, and it keeps working. The follow up appears in the transcript like any prompt, and the stop control works as usual.

When a goal ends

• A run that does not finish cleanly drops the goal.
• Stopping drops it. The terminal’s stop control, stopping or closing it from the orchestrator, and the stop loss all cancel the run, and the goal goes with it. Stopping while the check runs drops it too.
• After 20 checked turns without meeting the condition, the goal is dropped, so a goal that cannot be reached does not run forever.
• A check that fails or gives no clear answer ends the goal with Goal check failed.
• Goals are kept in memory only. Restarting the app clears them.

Every provider

The loop belongs to Warshall, not to one tool, so it works the same on Claude Code, Codex and local endpoint models. The first turn is an ordinary run. The follow ups continue the same conversation the way every terminal run does. The check runs on whichever provider your fallback model belongs to.

Edge cases

• /goal clear while the goal’s run is still going lets the run finish as ordinary work. No check follows it.
• A prompt you type while the check runs goes ahead. The follow up then finds the terminal busy and is dropped. The goal stays set, and the next finished run is checked again.
• A run refused before it starts, because the terminal is busy or the project folder is gone, sets no goal.
• If a cost warning appears and you press Cancel, the run is cancelled and the goal goes with it.
• Spaces around the condition are trimmed. Only the word clear on its own clears the goal.