Automations

An automation is a job your box runs without you: a prompt for an agent, or a shell script, plus a trigger. The result lands as files in the box and, if you like, you get an email with a summary and a link to them.

New automation walks you through three steps: What (Claude Code, Codex or a shell command, and what it should do), When (the trigger and schedule) and Finish (a name, the box, email and more options). Editing an automation shows the same settings on one page.

Agent or shell

• Agent runs Claude Code or Codex headless in the box with your prompt. Describe the outcome you want, such as "Write a one-page digest of…" or "Check… and note what changed", and the agent does the work.
• Shell runs a bash script. Use it when you already know the exact commands.

Agent runs use your own Claude or OpenAI account. Add a token or API key once under Toolhouse → Accounts: a Claude subscription token from claude setup-token or an Anthropic API key for Claude Code, and an OpenAI API key or your Codex sign-in for Codex. If an account is missing, the first step of the new-automation wizard asks for it inline. You can still create the automation and connect later: it won't run until you do, and its page and the Automations list say so. Automations and cloud sessions can read these values, but agents connected over MCP never see them.

You can also choose how much the agent may do on its own: full access (no permission prompts) or edits only (it can change files, and anything that would need your approval is refused).

Automations from apps

A desktop app connected to your account, such as monocode, can schedule its own automations in your box with any agent it runs, through the API. The app says how to start and install the agent and brings the agent's sign-in from your computer, so nothing needs connecting in Toolhouse. These automations show Managed by: An app connected to your account. You can pause, resume and run them here; everything else is changed in the app.

Triggers

Schedule

Pick a preset (every hour, every day at 9:00, weekdays, Mondays), or under More ways to start it choose Custom schedule and write a five-field cron expression. Every schedule has a time zone, which defaults to your browser's (press Change next to it to pick another), so "9:00" stays 9:00 across daylight-saving changes. The automation page lists the next three run times.

If wack was unavailable when a run was due and it's now too late, the run is recorded as skipped with the reason, so gaps are visible.

Webhook

In the wizard this is From another app, under More ways to start it. A webhook automation gets a secret URL:

POST https://api.wack.sh/hooks/whk_…

Send any body up to 256 KiB. wack saves it in the box for the run, outside the run folder. A shell script finds its path in $WACK_PAYLOAD, and an agent's prompt gets a line telling it where the payload is.

curl -X POST https://api.wack.sh/hooks/whk_… \
  -H 'content-type: application/json' \
  -d '{"event": "deploy", "ref": "main"}'

Treat the URL as a secret. Rotate webhook URL on the automation page replaces it.

Manual

Run now starts a run right away, even when the automation is paused. Apps can do the same through the API.

Runs

Runs on the same box take turns, one at a time and in order. Each automation can have one run waiting; extra scheduled runs are recorded as skipped instead of piling up.

A run:

1. wakes the box;
2. creates its own folder, /mnt/user-data/outputs/runs/<run id>, and passes its path as $WACK_RUN_DIR;
3. runs the agent or script, streaming its output to the run page as it goes;
4. collects every file saved in the run folder as the run's files;
5. lets the box go back to sleep if nothing else is using it.

A run can take up to 60 minutes and is stopped after that. Cancel on the run page stops it sooner. Either way, everything the run started in the background is stopped too. A run that finishes on its own leaves its background jobs running.

The run page shows a summary (the agent's final message, or the last lines of a script's or an app's agent's output, when they add to the transcript), the files, the full transcript and, for a failed run, what went wrong and how to fix it. Agents are asked to save anything meant for you in the run folder and finish with a two-line summary.

Snapshot runs

By default an agent works in its folder as it finds it, and whatever it changes stays there for the next run. An automation created through the API can ask for "workspace": "snapshot" instead. Its folder (cwd) must be a git repository, and each run then:

1. records the folder's current commit as the run's base, and discards uncommitted changes and untracked files (ignored files stay), so the agent starts from the last commit;
2. runs the agent;
3. saves everything the agent changed since the base, including any commits it made, as changes.patch among the run's files;
4. puts the folder back to the base commit.

changes.patch is a binary git diff (git apply --binary applies it) whose first line names the base commit:

# wack-base 3f2c9a0e…
diff --git a/src/app.ts b/src/app.ts
…

A run that changed nothing has no patch. If the folder isn't a git repository, the run fails to start and says so. Shell automations always use their folder as it is.

Notifications

Each automation emails you always, on failures or never. The email has the summary, the list of files and a link to the run. Apps that create automations through the API choose this with notify, which is always unless they say otherwise.

Templates

The Automations page offers ready-made starting points, grouped by category: Daily digest, Weekly report, Watch a page and Nightly check. Use on a template opens the new-automation wizard with every step filled in, ready to edit. Until you have an automation, the page also features three of them: pick one and press Get started.