Sandboxing

The shell adapter has the broadest blast radius of anything the platform exposes, because a flow can run any CLI on the user’s machine. For that reason, it carries its own layered enforcement on top of the system boundaries.

Lightweight rails (always on)

Every shell invocation gets:

Pinned working directory. The node runs in its cwd, which is anchored to the flow’s execution workspace.
Environment allow-list. By default, only HOME, USER, PATH, LANG, LC_*, TERM, and SHELL pass through (env: "scrubbed"). Everything else is dropped so secrets cannot leak through the environment.
Output byte cap. The combined stdout and stderr have a size limit. If the output goes over that limit, the child is killed and the node fails.
Hard timeout. A child that runs past its timeout is killed.

These rails protect against accidents such as a command writing to the wrong directory, a secret leaking through env, or a runaway process.

OS sandbox (opt-in per node)

A node can declare a capabilities object with net, write_paths, read_paths, and env.

Platform	Enforcement
macOS	`sandbox-exec` with a generated SBPL profile from the declared capabilities
Linux	Falls back to lightweight rails today; Landlock and network-namespace enforcement are planned
Windows	Declared capabilities recorded in the audit log; no OS enforcement yet

The filesystem jail

The fs adapter confines every operation to the node’s workspaceRoot. Paths are canonicalized and checked, and .. escapes and out-of-root symlinks are refused. The same confinement covers AI tool-loop calls, the agentic generator’s file operations, and manual edits. There is one jail for every door.

The destructive-action gate

A run pauses before any node that performs a destructive operation, such as a file delete, rm, git push, git reset --hard, kubectl delete, or similar. At that point it emits an awaiting-confirmation event so the user can confirm or cancel the step. The gate behaves as follows:

It is on by default, controlled by a Settings → Execution safety toggle.
It is overridden per run for unattended scheduled executions, because there is no UI to confirm them. The persisted setting still governs interactive runs.
It is bypassed by headless CLI/TUI runners, so review flows before you wire them into unattended pipelines.

Ahead of the gate, pre-apply verification statically scans proposed (generated) flows for destructive operations and sandbox-escape paths. It surfaces per-node warnings in the review modal before anything runs.

Audit log

Every shell invocation appends a JSON line to ~/.flow-studio/logs/audit/shell-YYYY-MM-DD.log. Each line records the command, cwd, capabilities, sandbox layer, exit code, and byte counts. The audit log sits alongside the app’s tracing logs so you can investigate everything in one folder. The file is append-only.