OpenCode 2.2.1 adds /goal: continued AI work still needs boundaries

What is new in the 29 October release

OpenCode 2.2.1, released on 29 October 2026, adds /goal so a session can continue across turns until an automated reviewer considers the objective satisfied. TUI and Desktop users can set, pause, resume or clear a goal. This changes session control, not the underlying AI model.

Development teams seeking fewer manual continuation prompts should first define verifiable acceptance conditions and bounded access. An AI completion judgment is not human acceptance. This 30 October article uses release 2.2.1 and change 59437. Friday Works opened the exact 2.2.1 TUI and inspected the actual /goal menu, without submitting a model task or testing the continuation loop.

How the session retains the objective

The maintainer describes goal state stored in session metadata. An idle hook reviews progress before the session becomes idle and can admit continuation input into the same execution, rather than assembling disconnected completion notifications.

The reviewer uses the session's own model and history, including tool results. Calling it a reviewer does not make it an independent audit. Incomplete requirements or tests can still produce a mistaken completion decision. Instead of “fix the form,” identify the form, defect, required inputs and acceptance tests, keeping that evidence separate from the model's completion statement.

Understand pause, resume and clear

The release provides /goal pause, /goal resume and /goal clear. The TUI exposes goal state and controls, while Desktop has a composer control. The article's capture is the TUI, not a reconstructed Desktop screen.

Change 59437 also describes stopping conditions for stalled progress, failures and unusable review results. Internal safeguards do not guarantee a runtime or spending cap; review rounds consume model resources. The change distinguishes interactive clients from opencode run, which does not provide the /goal slash command. Integrations must target the supported surface rather than copying interactive syntax into arbitrary scripts.

Continuation does not authorize more access

Repeated work remains subject to existing authorization. A long objective does not grant permission to access production data, deploy software or spend money. Separate proposals, validation and approval for external effects.

Start with a sample repository, synthetic data and least privilege. Restrict out-of-scope writes and retain diffs, command evidence and test results. The release also includes separately enabled image generation and scheduling; evaluating /goal does not require turning every experimental capability on.

Evaluate a defect with independently checkable results

A useful pilot is a small reproducible defect in an authorized sample repository with before-and-after tests. Compare ordinary sessions with goal-driven sessions under equivalent conditions, recording manual continuation prompts, elapsed time, consumption and remaining defects.

Acceptance should include the requested fix, no unrelated changes and stopping only with sufficient evidence. Test pause behavior and missing requirements on harmless data. These are proposed evaluations, not completed results. OpenCode's new mechanism merits investigation, but enterprise value depends on objective quality, verification and permissions rather than an assumption that entire workflows can run without review.

Further implementation reading

Friday Works provides implementation information and evaluation steps for business systems.