Destructive Actions

Overview

Some action nodes in Watchflows perform operations you cannot undo automatically — deleting files, overwriting existing content, running arbitrary shell commands, sending DELETE requests to remote services, or letting an AI Agent loose with write-capable tools. These are powerful, and they are also the easiest way to lose data by accident.

Watchflows surfaces destructiveness consistently at every UI surface where you make a decision: the canvas card, the node-library palette, the inspector banner, an inline warning under risky configuration fields, and a confirmation dialog at the moment you arm a workflow. The treatment is intentionally quiet but unambiguous — red is reserved exclusively for destruction so the signal stays meaningful.

Two Kinds of Destructive

Watchflows distinguishes two categories of destructive node:

• Destructive by identity — the node's whole purpose is destruction. Examples: Move to Trash. These nodes always wear the destructive treatment in the canvas, the library palette, and the inspector header, regardless of how they are configured.
• Destructive by configuration — the node is neutral until you configure it a certain way. Examples: Run Script with rm -rf, API Request set to DELETE, Write File in overwrite mode, Move File with overwrite enabled, Simulate Key Press bound to Cmd+Q, or Agent with destructive tools enabled. The destructive treatment lights up the moment your configuration trips a heuristic, and turns back off if you change it again.

The palette only flags identity-level destructive nodes — otherwise every shell-capable or Agent-capable node would be branded dangerous before you typed anything. The canvas badge and inspector banner are config-aware and update in real time.

What You Will See

• Canvas badge — a small red triangle in the top-right corner of the node card, plus a 2-pixel red accent strip down the left edge of the card body. Reads as quiet ambient signal rather than chrome.
• Inspector banner — a red-tinted banner above the node header that names the destruction in one sentence (“This script contains rm -rf…”, “DELETE removes the remote resource…”, etc.).
• Inline configuration hint — a red row appears directly under the specific field that caused the warning (the script body, the method dropdown, the overwrite toggle). It is informational only; it never blocks editing.
• Library palette — identity-destructive nodes get a red-tinted icon tile and a small red triangle after the node name, so you recognize them before you drag.
• Armed indicator — once a destructive workflow is armed, a small red triangle appears next to the Triggers pill in the toolbar. The tooltip names which destructive nodes triggered it.

Arming a Destructive Workflow

When you toggle Triggers on for a workflow that contains any destructive node, Watchflows presents a confirmation dialog before actually arming the workflow. The dialog lists every destructive node by name, includes a one-line description of why each is destructive, and offers two choices: Arm Anyway or Cancel.

This confirmation fires on every arm. There is no “don't ask me again” suppression, and no per-session memory: if you disarm a workflow and re-arm it, you will see the dialog again. Safety beats friction at the arming boundary — a destructive workflow's every fire is irreversible, and one extra click per arm is much cheaper than the regret of one armed by muscle memory.

If you cancel, the workflow is not armed. Once armed, the small destructive indicator on the toolbar pill stays visible so you always know a destructive workflow is live.

Recoverable Defaults

Where macOS offers a recoverable equivalent, Watchflows uses it by default. The clearest example is the Move to Trash node: by default it routes through the macOS Trash via NSWorkspace.recycle, so an accidentally trashed file can be restored. There is an explicit opt-in Permanent toggle on the node that bypasses the Trash and calls FileManager.removeItem directly — setting it to true surfaces an inline destructive hint on that field so you cannot enable it without seeing the consequence in writing.

Other destructive operations (overwrite-mode Write File, overwrite-mode Move File, API DELETE, Run Script with rm) do not have universal recoverable equivalents, so the warning system is the safety net. Read each inline hint before arming — it tells you exactly what will happen.

Imported Workflows

When you open a .watchflow file that came from outside your machine — downloaded, emailed, or AirDropped — Watchflows checks whether the workflow contains any node type capable of destruction. If it does, you see a confirmation dialog listing the destructive node types before the workflow opens. Locally-authored workflows skip this step.

This guard sits in addition to the per-arm confirmation. Together they make it hard for a maliciously crafted workflow file to silently load and run destructive nodes.