Sandboxing
How OpenVesper bounds what tools can do. Especially relevant for thefilesystem and shell plugins, which by design can touch your system.
Filesystem sandbox
The filesystem plugin uses a safePath() helper that resolves every requested path and ensures it stays within the configured workspace boundary.
What gets rejected:
- Paths with
..traversal that would escape the workspace - Symlinks pointing outside the workspace
- Absolute paths to system directories (
/etc,/root,~/.ssh)
By default, the workspace boundary is the current working directory when you ran the CLI. Configure with OPENVESPER_WORKSPACE in your env if you want to scope differently.
Shell sandbox
The shell plugin blocks dangerous command patterns before passing anything to a child process:
rm -rf /,rm -rf ~, and variants- Fork bombs (
:(){ :|:& };:) mkfs.*filesystem formattingdd if=/dev/...raw disk writesshutdown,reboot,halt- Network bind on privileged ports without sudo context
Every shell call also runs with a 30-second timeout by default. Override with the tool's timeout_ms input.
Permission flags on tools
Every tool declares what it needs:
| Permission | Auto-allow? | Behavior |
|---|---|---|
| (unset) | Yes | Pure / read-only computation |
external | Yes | Calls an external HTTP API |
filesystem | Yes (sandboxed) | File reads/writes, bounded by safePath |
shell | Yes (sandboxed) | Shell commands, blocked patterns rejected |
mutation | Prompts in interactive mode | Side effects: send, transfer, post |
Network restrictions
OpenVesper does not enforce network egress restrictions at the framework level. Tools call the APIs they're designed to call. If you want to restrict outbound traffic, run OpenVesper in a container or VM with a firewall.
Memory and conversation isolation
Each agent has its own memory and conversation state. An agent's memory file is not readable by another agent at runtime — the runtime loads only the active agent's MEMORY.md.