Long-running work

Use a long-running goal for work that needs repeated analysis, changes, validation, and follow-up instead of relying on one oversized message. EvoX keeps the objective, rounds, budget, progress, and stop reason attached to the goal and shows its state in Chat or Code.

Start a goal

In Code, enter /goal <goal>, or describe the desired outcome directly in a surface that supports goals. For a rough intention, use /write-goal <intent> when the built-in skill is available; it turns the intention into a verifiable completion contract before starting the goal.

If the expected result is still unclear, use /plan first to organize the approach. The underlying mechanism depends on the surface: Code uses a plan permission and tool gate, Chat produces a plan document, and Cowork uses task planning. Treat /plan as a planning entry point, not as one identical execution mode everywhere.

Starting a goal does not expand EvoX's file, plugin, or external-service access. Existing approvals, sandbox rules, and workspace boundaries still apply.

Define completion criteria

A goal should read like a completion contract so EvoX can tell when it is actually done:

For example:

Migrate the client login flow to the new authentication API while preserving behavior.
Done when the related tests pass and the project builds with strict type checking.
Scope: change only the login module and its tests; do not touch unrelated infrastructure.
Rerun the relevant checks after each change. Stop and ask before widening the scope.

/write-goal organizes an intention around an end state, observable proof, boundaries, an iteration method, and a stop rule. More specific criteria make progress easier to inspect and reduce the chance of reporting success without evidence.

Example goal

Long-running goals work best when the outcome and proof are explicit:

Fix the currently failing checkout tests. Rerun that test directory when finished
and confirm that no tests fail. Change only the checkout module and related tests.
If the external payment service is unavailable, record the blocker and stop instead
of claiming that the tests passed.

“Keep improving this project” and “fix every problem” are poor goal statements because they have neither a boundary nor a checkable finish line.

Adjust a running goal

The goal status strip shows the current objective, rounds used, progress, budget, and stop reason. Both Chat and Code expose goal state; Code has an explicit stop entry at the top of the workspace.

Manage an active goal through the goal tools rather than creating a second goal:

The current source confirms a stop entry, but not a dedicated edit or pause/resume control on every surface. Change the objective or budget through goal management tools or a follow-up instruction; whether pause/resume is visible depends on the current mode and version.

The mock below keeps only the goal status and follow-up entry point to show the information hierarchy; the exact controls depend on the current work surface.

Run goals in parallel

Code includes a split-and-parallel entry point. Enter multiple sub-goals at once to create multiple independent local Code sessions. Each session has its own context and initial sub-goal, which is useful for parallel analysis, implementation, and verification.

There are important boundaries:

• The feature creates multiple Code sessions; it is not the same as remote agent dispatch.
• Sessions normally use the same workspace source. Each sub-goal does not automatically receive a separate worktree.
• Batch fan-out requires the selected directory to be a usable Git worktree; otherwise EvoX blocks the operation or reports why it cannot proceed.

Code also provides a managed task-worktree panel for creating, viewing, switching, and cleaning up task worktrees. Cleanup handles uncommitted changes and can remove the corresponding EvoX task branch when Git permits it. Fan-out provides session parallelism; worktrees provide file isolation and lifecycle management. They are separate capabilities.

Keep the machine awake and receive notifications

On supported macOS desktop environments, open Settings > Advanced > Keep awake while running to prevent sleep during a long run. The entry appears only when macOS and the system capability are available; it is not a universal cross-platform switch. Long runs still have heat, battery, and operating-system limits.

EvoX has a general desktop notification surface, notification-permission checks, and a link to system notification settings. Keep notification text limited to a task name and next step; do not put secrets or sensitive file contents into system notifications. The current source does not confirm an unconditional goal-specific “completion always sends a system notification” binding. Whether a reminder appears depends on the surface, notification conditions, and OS permission; the conversation, goal state, or run history remains the source of truth.

Scheduled tasks versus goals

A scheduled task answers when the same work should run again. A goal answers what the next step is until an outcome is reached. They can be combined, but recurrence does not replace completion criteria. Creating a scheduled task also does not automatically create a worktree; a Code task uses the workspace selected when it was saved.

Related documentation

• Scheduled tasks
• Projects and chats
• Notifications
• Commands
• Slash commands
• Permissions

EvoX Docs · Features · Workflows