Automations

Automations turns your machine into an event-driven system: something happens, Genesi reacts. You draw the flow on a canvas — a trigger on the left, actions on the right — and a background daemon runs it whether the app is open or not.

Open Genesi AI Mode Monitor and select Automations in the sidebar.

How it works

Automations has two halves that are deliberately separate:

Workflows are saved as JSON under ~/.config/genesi-ai-monitor/automations/. The daemon picks up changes automatically, so a saved edit takes effect within seconds — no restart required.

Because the daemon is a user service, automations run as you, with your permissions, and stop when you log out.

systemctl --user status genesi-automationd

Building a flow

Drag a block from the palette onto the canvas, then drag from a block's right-hand dot to another block's edge to connect them. Select any block to configure it in the right-hand panel.

A workflow needs one event (when this happens) and at least one action (do this). Blocks run strictly in order: each one finishes before the next starts.

Events

Events are the triggers. Each one has a After it triggers setting: keep running (fire every time) or run once.

Actions

Running interactive programs

Run Script executes headlessly, with no terminal attached. Text-mode programs that draw an interface — htop, cmatrix, an installer with prompts — abort in that environment with errors such as $TERM="unknown".

Enable Run in a terminal window on the block and Genesi opens the command in a real terminal instead, picking the first available of konsole, foot, alacritty, kitty or xterm.

In that mode the output cannot be captured: the block reports success once the window has been launched, and nothing is passed to the next block.

Result ports: branching on success or failure

Run Script, AI Action, HTTP request and File operation expose two output dots instead of one:

• on ok — the block succeeded (a script exited 0)
• on error — the block failed (a non-zero exit status, or an error)

Drag a link from the dot you want. The flow then follows only the matching branch; the other one is marked Not taken and dims out on the canvas.

You can attach several links to the same dot — two blocks connected to the same on ok both run.

Passing data between blocks

Every block hands its output to the next one. You can use it in two ways:

• {input} anywhere in a text field — command, prompt, URL, notification body
• $GENESI_INPUT as an environment variable inside Run Script

# Run Script receiving the previous block's output
echo "previous block said: $GENESI_INPUT" >> ~/automation.log

An AI Action that does not mention {input} gets the incoming text appended to its prompt automatically, so prompts like "summarise this" work without extra wiring.

When a Run Script fails and printed nothing on standard output, its error text becomes the payload instead — so an on error branch can notify you with the actual message.

The Command sensor

The Command sensor runs a command and evaluates its result. It works in two different ways depending on where you place it.

As a trigger

Left on its own, it polls the command on the interval you set and fires when its condition is met.

As a checker

Connected after another block, it stops polling entirely and becomes a gate: it runs once per execution, and the flow continues past it only if its condition holds. If the condition fails, nothing downstream runs.

Leave Command to poll empty and it evaluates the incoming payload directly instead of running anything.

Fire when

The regex is tested against stdout and stderr combined — messages like command not found are written to stderr, so matching only stdout would miss them.

Commands run under /bin/sh, so shell messages can differ from what your interactive shell (bash, fish, zsh) prints for the same input.

Testing a workflow

Run now executes the flow immediately without waiting for its trigger, running the same chain the real event would. It is the fastest way to confirm the wiring.

The Run Log at the bottom of the canvas shows each step as it happens: the command being run, its output, the exit status, and — for a Command sensor — the exact text that was tested and why the condition passed or failed.

$ curl -s https://example.com/version.txt
v2.1.0
script exit 0
checker input: v2.1.0
checker: /v2\.1/ matched

If a checker is not behaving as you expect, this log tells you what it actually received, which is almost always the answer.

Enabling a workflow

A workflow only runs in the background once the Enabled switch is on. Disabled flows can still be tested with Run now.

The status line shows Listening in background when the engine is armed.

Safety

Automations run unattended, with your user's permissions. A workflow can delete files, install packages, terminate processes and reach the network.

• Test on non-critical data before enabling something destructive.
• Review any template or shared workflow before turning it on.
• Prefer Ask first over Automatic on AI Action blocks until you trust the flow.
• Remember that a trigger can fire while you are away from the machine.

Troubleshooting

Check that the engine is running:

systemctl --user status genesi-automationd
systemctl --user restart genesi-automationd

Follow its output live:

journalctl --user -u genesi-automationd -f

If a graphical action does nothing, confirm the workflow is enabled and check the Run Log for the failing step. The daemon resolves the desktop environment itself, so applications launched from an automation appear on your session normally.

If hotkey blocks never fire, verify group membership and log back in:

groups | grep input