What a task runs · Semantix

A trigger decides when. This is the what.

The new-task form offers three kinds, and they are genuinely different tools rather than three labels on the same thing. Pick by how much judgement the work needs.

Shell command#

The simplest, and often the right answer.

The command runs through sh -c, so pipes, redirects and $(…) all work exactly as they do in your terminal. npm test, a backup script, a curl to something that needs poking hourly.

No model is involved, nothing is sent anywhere, and it costs nothing but the time it runs. If the work has a deterministic answer, this is the kind to use — an agent asked to run your test suite is a slower, more expensive npm test.

Agent#

A prompt instead of a command: "read last night's failures and tell me which ones are the same bug."

You pick the model — any model you own, from the same picker the chat uses — and you write what the agent should do each run. The agent works in the task's directory with the tools it would have in a normal session.

What an unattended agent is allowed to do#

This is the part to read before you schedule one, because a task fires when you are not there and the permission gate has nobody to ask.

Safe — the default. Gated tools are denied. The agent can read and reason, but edits and shell commands are refused rather than queued for an approval that is never coming. A task that needs to write will fail honestly instead of hanging.

Accept edits — file edits are auto-approved; shell commands are still gated.

Full autonomy — everything is auto-approved.

Important

These modes exist because an unattended run cannot ask you anything. The interactive permission gate is a real protection, and choosing Full autonomy for a scheduled task is choosing to switch it off while you are not watching. That is sometimes exactly right — a task in a scratch directory, or work you would rubber-stamp anyway. It should be a decision, not a default you clicked past.

Start a new agent task on Safe and run it by hand. You will find out what it actually tries to do before you grant it anything.

Agentic Flow#

A saved flow — several agents wired together on a canvas — run end to end, in the daemon, on the task's schedule.

You pick the flow, and optionally supply input text handed to the flow's trigger on every run.

Note

A flow is referenced, not copied. The task stores which flow to run, so editing the flow changes what the next fire does. That is usually what you want — fix the flow once, every task using it improves — but it does mean a task's behaviour can change without the task being touched.

Settings every task shares#

Whatever it runs, a task carries the same execution settings:

Working directory — where the task runs. Agent and flow tasks need one, and default to the project's path; a shell task can run anywhere.

Timeout — how long before the run is cut off. The default is 600 seconds.

Overlap — what happens when a run is still going and the next one is due. Skip (the default) lets the running one finish and passes on this fire. Allow starts the second anyway. Skip is the safer choice for anything that writes.

Environment variables — KEY=value, one per line, for that task's runs.

Scope — one of your projects, or global. A global task belongs to no project and still runs in its own directory.

A project task has one more choice: Only run while this project is open in the studio. Left unchecked — the default — the task fires whenever its trigger fires, even with another project open, or the studio closed. Checked, the project must be open for it to run at all. Use it for work that only makes sense in context, and leave it off for anything that should happen overnight.

Note

Skip exists for a specific failure: a task that fires every minute and takes ninety seconds will otherwise pile runs on top of each other until something gives. It is also the blunt guard against a task that triggers itself — an agent that runs on file saved and then saves files.