Approving a file write
The card names the file being changed, and says exactly what would be remembered if you allow it always.
Security
See what will change, then allow it
Tool calls fall into read, write, shell, network and meta, and risk is low, medium or high. The default mode allows reads only; anything that changes something asks in an approval dock that does not cover the conversation.
Permission modes
You decide how often it asks
In every mode, hard-deny rules run first: sensitive paths, invalid manifests and sandbox limits.
- Confirm writes. The default. Reads are allowed; writes, shell commands and network requests ask for approval.
- Confirm all. Every tool asks for approval, reads included.
- Auto-verify. In chat, low and medium risk are allowed automatically with an audit trail, and only high risk asks. Headless runs use a separate reviewer queue.
- Allow all. Everything outside the hard blocks is allowed, but access outside the allowed folders still asks.
In the app
Approvals, isolation and a record
An approval card shows what runs, where, and under which isolation. Always allow is bound to exactly that tool, input and working folder.
Approving a browser action
In agent tabs an approval lasts until Ave restarts; in your own tabs, clicking and typing ask every time.
The OS sandbox
Seatbelt on macOS, bwrap on Linux and srt-win on Windows confine tool execution at the operating-system level.
The audit log
~/.ave/audit.log is HMAC-chained, and audit records never contain raw secrets.
Also decided for you
Allowed folders
They start with the project root, ~/.ave, a private scratch folder and the system temporary folder (plus /tmp on macOS and Linux), and grow through permissions.additionalDirectories in settings. Anything outside them asks separately.
Choose the reviewer
Validation off (auto-pass), rule-based validation, LLM validation, or strict, where every request that changes something waits in a queue for you.
Policy files
Users and administrators can each keep a policy.json, and a valid administrator policy locks the settings it covers.
Verified installs
Plugins follow the same rules
Plugins run in their own processes, and the host rates the risk of every call. A plugin cannot lower it.
- Pinned by hash. Installs are bound to a commit and SHA-256, and checked again at every launch.
- Declared domains only. Network goes only to declared domains, and every redirect is checked again.
- Recalls. A source can disable or uninstall a specific version; a recall applies only to installs from that source.
Questions
What does Always allow remember?
Exactly that tool, input and working folder. If the target name contains a wildcard, Ave won’t save the rule and suggests Allow once instead.
What if the reviewer fails?
The request is held, not passed. LLM validation can raise a risk rating, never lower it.
Who approves in routines and headless runs?
Anything above low risk goes to a deferred queue and waits for you.
Which paths are always blocked?
Sensitive paths, such as keys under ~/.ssh and .env files, are blocked in every mode.
Do secrets reach the model?
API keys and other credentials are always removed before anything is sent, whatever the settings say. Personal data such as email addresses, phone numbers and card numbers is replaced with [REDACTED:*] when you turn on PII Redaction (off by default), and the count is recorded in the audit log.
Can a plugin start a conversation by itself?
A plugin with the host:overlay capability can suggest one, but it starts only when you accept it, and write, shell and network tools inside it ask again.
What is different on Windows?
srt-win confines files and network, not processes, and isolation between plugins is available on macOS and Linux only.
Is the OS sandbox on by default?
No. You turn it on, and it needs a restart. With the sandbox on, network is denied by default.