Automations
An automation watches what your terminals print and answers when something specific shows up. The classic use is agents: when Claude Code's context gauge passes 80%, type "prepare to do context hand-off" into that terminal; when a build prints FAILED, post to a Slack channel. Automations can also run on the clock, such as sending a message to a set of terminals every weekday at 09:00.
Automations run for every open terminal they target, including tabs you aren't looking at.
Where to Find Them
- Settings → Automations lists every rule. Use + New automation to create one and ☰ Activity log — all to see what your rules have done. The All, Active and Needs attention filters narrow the list.
- Right-click a terminal → Automations shows the rules armed on that terminal and offers New automation for this terminal, which starts a rule already pointed at it. For a rule that targets specific terminals, Add to an existing automation adds this one.
- In Canvas Mode, a node's right-click menu has the same Automations section.
The editor opens over the app without blocking it, so you can keep using your terminals while you build a rule. Ctrl+S saves and Esc closes.
How a Rule Is Built
A rule is a chain of steps. You drag steps from the palette onto the editor's canvas, wire them together, and set each one up in the panel on the right.
| Step | What it does |
|---|---|
| Watch output | Chooses which terminals to read and how. |
| Read a value | Looks for text in the output, and can keep part of it (a number, a word) for later steps. |
| Compare it | Decides whether what was found should fire the rule. |
| Wait | Holds before sending, or starts the rule at a time of day. |
| Send to terminal | Types a message into a terminal. |
| Send to webhook | Posts a message to Discord, Slack, Microsoft Teams or any JSON endpoint. |
An output-driven rule needs Watch output, Read a value and Compare it, then at least one of the two Send steps. A scheduled rule starts with Wait set to a time of day and doesn't read any terminal. A webhook is always a destination; it never starts a rule.
Watch Output
Pick the terminals:
- These terminals: a fixed list you choose. A rule with an empty list can't be switched on.
- Terminals matching a rule: a filter on terminal id, title, folder or program, with exclusions. It's re-checked as terminals open and close, so a filter that matches nothing today is allowed.
A live preview shows how many terminals match. Then choose what to read, New output as it appears or What's on screen right now, and how often: Every time new output arrives or On a timer (no faster than every 250 ms).
Read a Value
Type the words to look for, or switch to a regular expression for anything more precise, for example ctx:(\d+)%. Choose what to keep: The number in brackets (a capture group) or The whole matched text. The panel's Test run shows what your pattern finds in a real terminal's recent output, so you can check it before saving.
Compare It
Choose the kind of thing you're checking:
- A reading that stays true, like a percentage or a status line. It's checked against the last 200 lines, and fires again only when a new value is printed.
- Something that happened, like "Build failed". It fires once each time it's printed.
Then add comparisons against what was read: contains, equals, starts or ends with, matches, is empty, or a number greater than, less than or equal to a value. Several comparisons combine with AND or OR.
Wait
- After the comparison passes: hold for a number of seconds (at least 1), then send.
- At a time of day: pick a time and the days of the week. Times are your computer's local time and follow daylight saving changes. A schedule fires at most once a day. If TermFlow wasn't running (or the computer was asleep) at that time, the run is skipped rather than made up later.
Send to Terminal
Type the message, then choose where it goes, The terminal that matched or Every watched terminal, and whether to Type it and press Enter or Type it, don't press Enter. Insert snippet… puts one of your snippets into the message.
Turn on Insert captured values to use tokens in the message:
| Token | Becomes |
|---|---|
$0 | Everything the pattern matched |
$1 … $9 | Numbered capture groups (${10} and up need braces) |
${name} | A named capture group |
${terminal.id}, ${terminal.title}, ${terminal.cwd} | The terminal that matched |
${time} | Local time, YYYY-MM-DD HH:MM:SS |
$$ | A literal $ |
Send to Webhook
Choose Discord, Slack, Microsoft Teams or Custom JSON, paste the webhook URL (it must be https), and write the message. TermFlow formats the body for the chosen service; with Custom JSON it posts your body as written, which must be valid JSON. A preview shows the request with the URL masked.
Anyone holding it can post into that channel as this integration. TermFlow hides it by default and masks it in logs and errors.
Capture tokens in a webhook message are only replaced when Insert captured values is on. Otherwise they're posted as written.
Testing, Saving and Switching On
The top of the editor has:
- Repeatable / Runs once. A run-once rule completes after it fires; Re-arm lets it fire again.
- Enabled, which switches the saved rule on or off. It always runs the saved version, so save your changes first.
- ▶ Test, a dry run. It checks your unsaved rule against an open terminal and tells you what would happen, without sending anything.
- ⧉ Duplicate, Delete, Cancel and Save.
TermFlow checks a rule before it runs and explains what's missing ("Pick at least one terminal for this rule to watch.", "Provide an https webhook URL." and so on). If you save a switched-on rule that isn't valid, it's saved switched off and you're told why. Closing with unsaved changes asks whether to save, keep editing or discard. Deleting a rule also deletes its activity history; switch it off instead if you want to keep that.
The Activity Log
Each rule's Activity shows when it fired, on which terminal, what it did and why. ☰ Activity log — all shows every rule together. The log keeps the last 200 entries per rule across restarts.
Ordinary checks that didn't fire aren't recorded. To see them while you debug a rule, turn on Log every check for that rule for a while.
An honest note: Sending to a terminal types into whatever program is in the foreground, just as you would. Point a rule at the right terminals and be deliberate about Type it and press Enter. A message that contains the text its own rule is looking for can trigger the rule again; the editor warns you about that. Rules are stored on this computer and can only be managed in the app: there's no REST or MCP API for automations.
Next Steps
- Snippets and command history
- Canvas Mode: see which terminals have armed automations.