Stashbase

Filesystem restrictions

Deny agent reads and writes to sensitive paths

Use [filesystem] to deny reads and writes to explicit paths:

.stashbase/agents/coding.toml
[filesystem]
deny_read = [".env", "~/.ssh", "~/.aws"]
deny_write = [".git", "~/.ssh"]

Paths may be relative to the working directory, home-directory paths such as ~/.ssh, or absolute paths. A matching path also covers its directory descendants. Entries are explicit path prefixes, not globs; invalid paths and glob characters are rejected during validation.

Platform enforcement

On macOS, filesystem restrictions use Seatbelt. On Linux, Stashbase prefers a systemd user session and can use bubblewrap as a fallback. If no supported enforcement backend is available, validation and launch fail closed rather than silently weakening the policy. Bubblewrap restrictions are inherited by descendants.

Existing file descriptors and data already loaded into process memory are outside filesystem restrictions. These controls are path restrictions, not general process-memory, administrator, or root isolation.

Validate and troubleshoot

Validate a profile before launching the agent:

stashbase agent validate --profile coding
stashbase agent validate --profile coding --profile-source directory

Filesystem denials observed directly by the proxy are recorded as filesystem_denied audit events with path and operation metadata. A nested tool may instead surface the native operating-system error it received.

See Command restrictions for executable controls and Run and secure agents for the broader security boundary.

On this page