Workspace Actions

Every project has commands you run over and over: the test suite, the dev server, the deploy script, the “check what broke overnight” prompt.

Workspace Actions are those commands, saved per workspace and startable with one tap — including from your phone, where typing them would be miserable.

Two kinds

Kind	Runs	Good for
Terminal	a shell command in a terminal card	tests, builds, dev servers, scripts
Agent	a prompt in an agent session	recurring review, triage, summaries

An agent action can pin the tool, the model and the permission mode, so “run the nightly cleanup in YOLO with Codex” is one saved thing.

When they run

Four triggers:

• Manual — you tap it.
• Schedule — every N minutes, or daily at a fixed time.
• Restart — when the host comes back up.
• Card — from the card the action belongs to.

The scheduler runs on the host, so scheduled actions fire whether or not any device is connected.

One saved thing, four ways to start it. An agent action reads its memory file first, so a recurring run gets better instead of repeating itself.

The rerun loop

A terminal action does not just run and die. When it finishes, the card waits at a rerun prompt: press Enter and it runs again, in the same card, with the same scrollback above it.

That turns “run the tests” into a loop you can drive with one key, and it is why a live action card is reused instead of piling up new cards.

Action memory

Every action has a memory file on the host. An agent action is told to read it before starting and may write durable learnings back into it.

This is what makes a recurring agent action get better: the third nightly run knows what the first two discovered, without you re-explaining it.

Run log

Each run is recorded with what triggered it, when it started and finished, and its exit status. That log is how you find out that the scheduled job has been failing since Tuesday.

Details

• Triggers on the wire: manual, schedule, restart, card.
• Schedules are either {kind: interval, minutes: N} (N ≥ 1) or {kind: daily, at: "HH:MM"} in 24-hour form. Anything else is rejected.
• Action memory lives at ~/.offsite/action-memory/<action_id>.md and is seeded with a short header. Deleting the action deletes its memory file.
• The scheduler holds a lock file (~/.offsite/action-scheduler.lock) so two host processes cannot double-fire an action.
• Run mode rerun_on_enter requires a command; the loop is only re-triggered while its prompt is actually up, so a busy card is never interrupted.
• A terminal action can choose what happens when it completes — keep the card, or close it.
• An empty Actions list opens straight into New Action…, so the first action is one dialog away.