Automations for Cap Desktop

[richiemcilroy]

Users can define automation rules in Cap Desktop (Settings → Automations) that run automatically when something happens in Cap — no manual steps after each capture.

Each rule is when this happens → optionally if these conditions match → do these actions. For example: after a screenshot, save a copy to ~/Shots and POST a webhook; after a studio recording finishes, export an MP4 and upload it; skip opening the editor for headless screenshot workflows.

Triggers: screenshot taken, recording started/finished (studio or instant), upload completed, video imported, recording deleted.

Conditions (optional): capture target (display/window/area), recording mode, duration min/max, window title contains, organization.

Actions: copy to clipboard, save to folder, export, upload + copy link, reveal/open file, run a shell command, send a webhook, OCR to clipboard, notify, open/skip editor, apply a preset, delete local files.

Rules are stored once and shared with the CLI — cap screenshot, cap record, and cap upload honor the same automations (desktop-only actions like clipboard, OCR, notifications, and open editor are skipped on CLI). Inspect active rules with cap automations list.

Greptile Summary

This PR introduces a full automation engine for Cap Desktop: users define trigger → conditions → actions rules in Settings → Automations, and the same rules are honored by the cap CLI. The shared cap_automation crate owns the data model, evaluation logic, and sanitization helpers; platform-specific AutomationHost impls (desktop and CLI) carry out the actual I/O.

• New crate (crates/automation): rule types, engine (evaluate / run), template helpers, sanitize_filename_component (strips path separators and {/} to close the previously-reported window-title injection vector).
• Desktop host (apps/desktop/src-tauri/src/automation.rs): all 13 capabilities implemented; open_file now uses tauri_plugin_opener (not reveal_path); notify now calls both apply_filename_template and apply_body_template (fixes the previously-reported unsubstituted template variable issue).
• CLI host (apps/cli/src/automation.rs): nine headless-compatible capabilities; shares the rule store from Cap Desktop's Tauri plugin-store file; cap automations list added.

Confidence Score: 5/5

Safe to merge; all previously flagged blocking issues are addressed and the new automation engine is well-tested.

All three previously reported issues (desktop open_file calling reveal_path, notify ignoring template context, and window-title template injection) are now fixed. The automation engine has a comprehensive 827-line test suite, the shared data model is clean, and the lifecycle hook placements in recording.rs are correct with no double-trigger paths. The one remaining finding — the CLI reveal_in_file_manager calling the same helper as open_file on macOS — is a behavior mismatch rather than a data-loss or security concern.

apps/cli/src/automation.rs — reveal_in_file_manager and open_file share open_path_or_url, making them identical on macOS.

Important Files Changed

Filename	Overview
crates/automation/src/lib.rs	Core automation engine. Template injection vector fixed: sanitize_filename_component now strips { and }. OrganizationIs condition stays inert with a clarifying comment.
apps/desktop/src-tauri/src/automation.rs	Desktop automation host — all previously reported issues addressed. open_file uses tauri_plugin_opener, notify runs both template passes, template injection prevented.
apps/cli/src/automation.rs	CLI automation host — RevealInFileManager and OpenFile call the same open_path_or_url helper; on macOS reveal behaves like open (no -R flag).
apps/desktop/src-tauri/src/recording.rs	Automation hooks added at all lifecycle points. Studio automation fires once per recording with no double-trigger. Editor-behaviour override logic defers to automation rules correctly.
crates/automation/src/types.rs	Clean data model; serde defaults well-applied, specta types registered correctly.
apps/desktop/src/routes/(window-chrome)/settings/automations.tsx	New 1476-line settings UI. TRIGGER_CONTEXT / ACTION_REQUIRES tables mirror the Rust context population accurately.
apps/desktop/src/utils/automations.ts	TypeScript utilities over specta-generated bindings. DeepRequired wrapper ensures editor always builds fully-populated objects.
apps/desktop/src-tauri/src/camera.rs	Preview texture sizing reworked for aspect-ratio-correct cover scaling; new unit tests validate caps and cover invariants.
apps/desktop/src-tauri/src/hotkeys.rs	Hotkey screenshot handlers now gate the editor on should_open_screenshot_editor, supporting SkipEditor rules.
crates/automation/src/tests.rs	827-line test suite covering evaluate, run, condition matching, sanitize_filename_component, shell quoting, and template substitution.

_{Reviews (4): Last reviewed commit: "style(automation): use char-array patter..." | Re-trigger Greptile}

[polarityinc]

Paragon Review Skipped

Hi @richiemcilroy! Your Polarity credit balance is insufficient to complete this review.

Please visit https://app.paragon.run to finish your review.

[superagent-security]

Superagent found 2 security concern(s).

[superagent-security]

P0: Automation rules loaded from writable store enable arbitrary command execution

Run command action executes programs from user-writable store without integrity protection.

Sign automation rules or sandbox command execution to prevent unauthorized persistent execution.

AI prompt

Check if this security scanner issue is valid. If so, understand the root cause and fix it. If appropriate, update or add tests. Keep the change focused and preserve intended behavior.

<file name="apps/cli/src/automation.rs">
<violation number="1" location="apps/cli/src/automation.rs:233">
<priority>P0</priority>
<title>Automation rules loaded from writable store enable arbitrary command execution</title>
<evidence>run_command executes arbitrary programs and shell commands from automation rules loaded from dirs::data_dir()/so.cap.desktop/store, an unencrypted user-writable JSON file. Any process with user filesystem access can modify rules to persistently execute commands triggered by screenshots and recordings.</evidence>
<recommendation>Add cryptographic signatures or integrity checks for automation rules, sandbox command execution, or require interactive user confirmation before running shell commands from stored rules.</recommendation>
</violation>
</file>

[richiemcilroy]

@greptileai please re-review

[richiemcilroy]

hey @greptileai please re-review the pr

[richiemcilroy]

hey @greptileai please re-review the pr

[superagent-security]

P2: deleteLocalFiles omitted from dangerous-action warning in automation editor

DANGEROUS_ACTIONS only lists runCommand and webhook, omitting deleteLocalFiles which permanently deletes directories.

Add "deleteLocalFiles" to DANGEROUS_ACTIONS so users see a warning before creating destructive rules.

AI prompt

Check if this security scanner issue is valid. If so, understand the root cause and fix it. If appropriate, update or add tests. Keep the change focused and preserve intended behavior.

<file name="apps/desktop/src/utils/automations.ts">
<violation number="1" location="apps/desktop/src/utils/automations.ts:87">
<priority>P2</priority>
<title>`deleteLocalFiles` omitted from dangerous-action warning in automation editor</title>
<evidence>export const DANGEROUS_ACTIONS: ActionType[] = [&quot;runCommand&quot;, &quot;webhook&quot;]; excludes &quot;deleteLocalFiles&quot;, even though that action calls remove_dir_all on project_path in both the desktop host (tokio::fs::remove_dir_all) and the CLI host (std::fs::remove_dir_all). The editor only shows the amber dangerous-action banner when an action type is in this array, so adding a delete-files rule produces no warning.</evidence>
<recommendation>Add &quot;deleteLocalFiles&quot; to the DANGEROUS_ACTIONS array in apps/desktop/src/utils/automations.ts so the destructive action is surfaced to users alongside runCommand and webhook.</recommendation>
</violation>
</file>