Croli
Automations
Automations in the left sidebar are a saved prompt plus a schedule: when the time comes, Croli opens an unattended session of its own, sends the prompt to an agent, and lets it finish the job. The usual shapes are a code review every morning, or a dependency check every Monday.
There are two ways in: Automations in the left sidebar, and the quick-actions menu in the status bar. The sidebar row can be switched off under View options → Navigation items; doing so only drops the shortcut, the status bar still gets you there. Its position is not in the address bar, so a reload lands you back in the conversation workspace.
While there are failures you have not looked at, the entry carries a red number — on the sidebar row and in the status-bar menu both — and opening the page clears it.
Creating one
Create in the top right is a split button with three routes:
| Route | What it does |
|---|---|
| Set up manually | Straight to the form, covered field by field below |
| Create with current agent | Opens a conversation where you describe in plain words what should happen and when, and let the agent build it |
| Start from a template | Seven ready-made templates; picking one also opens a conversation, with the prompt already filled in |
The last two run on Create automations under Extension tools, which is off by default. While it is off both routes still work as far as the conversation — it opens, the prompt is sent — the agent just cannot save the result, and replies that a setting is in the way.
The seven templates
| Template | Suggested trigger | What it does |
|---|---|---|
| Code review | Weekdays at 9 | Reviews recent changes for bugs, regressions and quality problems |
| Dependency updates | Mondays at 9 | Finds outdated dependencies and proposes safe upgrades |
| Test coverage | Mondays at 9 | Finds uncovered code paths and fills in the missing tests |
| TODO sweep | Manual only | Collects TODO and FIXME comments and sorts them by priority |
| CI triage | Manual only | Triages recently failing checks and proposes fixes |
| Release notes | Manual only | Summarizes what changed since the last release into a changelog |
| Security audit | Mondays at 9 | Scans for vulnerabilities and risky patterns, and reports what it finds |
A template is only a starting point — name, prompt, schedule and folder are all still editable afterwards. The grid is laid out on the page itself while the list is empty; once you have automations, reach it through Start from a template in the Create menu.
What is on the form
| Field | Default | Notes |
|---|---|---|
| Name | empty | Required. Each run's session is titled after it |
| Agent | Claude Code | Which CLI runs it |
| Prompt | empty | Required. The chat composer, so @ mentions, / commands and $ skills all work |
| Workspace folder | the first folder | Required. Where it runs |
| Branch | default branch | Only shows up when the worktree box is unticked, and only local branches are offered |
| New worktree per run | ticked | A checkbox — see the next section |
| Trigger | On a schedule | The other is Manual only |
| Schedule (cron) | Weekdays at 9 | Three presets plus a schedule builder; only on a schedule |
| Timezone | this machine's | Display only, and also only on a schedule |
The small bar at the bottom of the prompt box holds the chosen agent's mode and config; its contents follow the agent, and an agent with nothing to configure shows no bar at all. Below the schedule sits a live Next run preview. There is no enabled switch on the form — a new automation is enabled from the start, and you toggle it on its card afterwards.
Isolation
New worktree per run is ticked by default: every run gets its own Git worktree and branch, so runs never collide with each other and never touch the files you are editing.
Untick it and the run happens in that folder directly (the detail pane calls this "Run in the folder"), and the screen says as much: runs can collide with your uncommitted changes. In that case you may also pin a local branch — if a worktree for that branch already exists, the run happens there; otherwise the branch is checked out in the folder itself, and if that working tree is not clean the run fails outright instead of switching under you.
The schedule
Standard five-field cron (minute hour day-of-month month day-of-week). The three presets are hourly, daily at 9, and weekdays at 9. Rather than writing it by hand, click Open schedule builder and pick a frequency: every N minutes / hourly / daily / weekdays / weekly / monthly / custom.
The list and run history
Each card carries four tags: the schedule (Manual for manual-only ones), the agent, the folder, and the timing — "Next in {rel}" while it is scheduled and enabled, otherwise how long ago the last run was. The enabled switch rides the title line; the dot on the agent's icon is the last run's outcome, with a spinner beside it while one is going.
Filters along the top: All / Enabled / Disabled, search (name and prompt only), and a folder filter.
Right-click and the ⋯ menu hold the same actions: Run now, Disable / Enable, Edit, Delete. Disabling only stops the schedule — Run now still works — and re-enabling recomputes the next run from that moment on.
Clicking a card opens its detail: trigger, agent, folder, isolation, next run, config, prompt, and below that the Run history (up to 100 entries, with a refresh button). Each entry carries a status (Running / Succeeded / Failed / Cancelled / Skipped) and a start time, with a duration once it has finished; an error is shown when there is one (skipped runs included — theirs says the previous run was still going), otherwise the agent's closing reply. View conversation only appears when that run actually produced a session, and Cancel run only while one is running.
What a run looks like
- Every run is a fresh unattended session. It reuses no earlier connection and sees nothing of the previous run's context. The session is titled after the automation, not the prompt.
- A run has no time limit — the agent may take as long as it takes. It is only failed outright when the backend has lost track of it (the process doing the work went away).
- If the previous run is still going, this one is skipped (recorded as Skipped). Runs never queue up or overlap.
- Nothing fires while Croli is closed. Slots missed while it was shut or asleep are not made up: the next start simply computes the next slot forward, rather than replaying every minute it was away. It also marks any "running" row left behind by an unclean exit as failed.
- Failures raise no system notification; that failure count is the only signal.
Worth knowing
- A manual-only automation is just a saved prompt: no schedule at all, it runs when you press Run now. This is the shape to use for a shelf of tasks you trigger by hand.
- Delete is a soft delete: it leaves the list and the schedule stops, the conversations it produced are kept, and the run history is still in the database (which is what the dialog means) — you just cannot reach it from the interface any more.
- Run history is kept for 30 days.
- The worktrees and branches created per run are never cleaned up automatically; they outlive the run history. A frequently scheduled automation is worth tidying up after now and then.
- Automations run in the backend, not in the interface: other clients connected to the same Croli backend see the same list and the same run history.
- The timezone is fixed to this machine when you create it and cannot be changed from the interface afterwards — editing still shows the one it was saved with. To follow a new timezone, delete it and create it again.