Troubleshooting

When a workflow doesn't do what you expect, the run history is the first place to look — it shows exactly which step ran, what it produced, and where it stopped.

A step failed

Open the run and find the step marked failed; it carries the error from that node. Common causes:

• HTTP errors — check the URL, method, and headers on the task.http node. If it needs auth, confirm the ${NAME} reference points at a setting you've defined.
• Expression errors — a task.transform or task.branch expression that references a field the previous step didn't return. Inspect the prior node's output in the run to see the actual shape.

An AI step isn't working

• Make sure the AI CLI you're targeting is installed and signed in — AI steps run as your own authenticated CLI.
• If you need a structured result, give the agent.run node a decision schema so it returns typed fields you can branch on, instead of free text.
• Treat any content the workflow fetched as untrusted data in your prompt, never as instructions.

An AI step says it's blocked

An unattended agent has nobody to answer a permission prompt, so a step that needs to act (write files, run git, install packages) stops — it's waiting for an approval that will never come. The fix is to tell that step it's allowed to act, with the access field on the agent.run node:

• Start with access: broad. It auto-approves writing in the working tree plus git and the common package managers — enough to unblock almost every CI-style step — while keeping everything else sandboxed. It needs no special switch, so it's the right first move.
• Need to act freely but only inside its own folder? Use access: full + scope: workflow-folder. This is the default scope for full: the step runs unattended and can change anything inside its workflow's own folder, nothing outside — and it needs no master switch. It's the cheap way to unblock a headless agent that only works in its own folder. (Honest limit: file edits are guarded to the folder, but a shell can still cd out — it's not a hard sandbox.)
• Use scope: machine only when the step genuinely needs the whole computer. That's the unsandboxed run — it can change anything on this machine — and it requires the workspace-level Allow full-access steps master switch (Settings → Full access, off by default). If a machine-scoped full step fails with "Full access is off…", that switch is off — turn it on, drop to scope: workflow-folder, or lower the step to broad.
• Leave standard for steps that only decide or draft. A pure classify/summarise step never needs elevated access; only give a step more reach when it actually acts.

Every step that runs with broad or full is recorded in the run history — for full, noting whether it ran with folder scope or machine scope — so you can always see which steps ran with elevated access and how far.

A rovo step does nothing or errors on launch

If an agent.run node with runner: rovo and a model: set fails immediately or produces no output, it's likely the --model flag. Rovo Dev's exact model-flag name is unverified, and an unrecognised flag can break the whole invocation — so Destaris does not send a node's model: to Rovo by default; Rovo runs on its own known-working default model instead. Just remove the model: from the node (or leave it — it's ignored for Rovo) and the step should run. codex, gemini, and claude are unaffected.

A scheduled workflow isn't firing

• Confirm the workflow is saved and its trigger.cron schedule is what you intend.
• The app needs to be running for scheduled workflows to fire on your machine.

It's processing the same items repeatedly

That's the dedupe pattern's job. Add task.cache-unseen and task.cache-mark around the work so each item is handled once, and pick a stable key that uniquely identifies an item.

Still stuck?

Check the node reference for the exact configuration of the step that's misbehaving, and review the workflow as YAML — sometimes the file makes a wiring problem obvious that the canvas hides.