Linux Sandbox Isolation in Capka
Every Capka chat gets its own Linux sandbox. The agent can run code and use installed tools without sharing a working directory or execution context with another chat.
How sandbox isolation works
A sandbox contains the chat workspace, tools and code execution environment. Containers are never privileged, use no-new-privileges, drop Linux capabilities, and run agent commands as UID 1000:1000. They cannot access the host filesystem. Separate users receive separate workspace mounts, and a session only mounts the requesting user’s paths.
Workspace files persist between steps and sessions, while task execution continues on the server if the browser tab is closed. This lets long-running file jobs finish without keeping a client connection open.
What can run inside a sandbox
- Python, Node.js and Java programs.
- Document and spreadsheet work through LibreOffice.
- Audio and video processing through FFmpeg.
- Browser automation through Playwright.
- OCR, ImageMagick, Pandoc, Graphviz and other packages required by a task.
Hardening for untrusted users
An unprivileged runc container is the default boundary for trusted users. Public or multi-tenant deployments should add gVisor for a user-space kernel and rootless Docker so a container escape does not equal host root. Sandboxes also have memory, CPU, PID and file-size limits. Network egress is off in a fresh instance until an administrator enables it; deployments can hard-disable it or restrict it to an explicit host allowlist.
Read the security documentation and the repository SECURITY.md before exposing an instance publicly.