The standard sandbox
By default, every runtime runs under the standard sandbox policy. It:- Limits writes to the workspaces assigned to the session, a private state and temp directory per session, and the credential stores that session’s runtime declares. On macOS, the rest of your home directory, other users’ files, and shared locations are also hidden from reads. On Linux the rest of the filesystem stays readable, but not writable.
- Allows read-only access to the tool directories agents need. There’s no blanket access to the operating system’s credential store: the macOS keychain is opened to a session only when the machine’s shared login lives there.
- Doesn’t restrict the network. Agents can reach the internet to install packages and call APIs, and they can start local servers and connect to local ports.
Where the sandbox runs
On macOS too,
KANAERU_RUNTIME_EXTERNALLY_ISOLATED=1 turns Seatbelt off, so only set it on a host that’s isolated some other way.
Settings
Set these in the Agent Manager’s environment on the machine.Running your app with Docker denied
deny only blocks the Docker CLI and the Docker daemon. Agents can still run, test, and serve your app as ordinary processes inside the sandbox, such as npm run dev or a Python server, and connect to it on a local port. Keep anything the app writes, such as a local database’s data directory, inside the workspace. If your app can only run under Docker Compose, leave Docker set to allow on that machine, ideally one dedicated to Kanaeru.
Capacity
The Agent Manager sizes how many agents run at once from the machine’s memory and CPU. Roughly:- 2 to 4 on small machines
- 8 on 4 cores with 8 GB
- 12 on 8 cores with 16 GB
- 15 at most
Agents that are idle between turns don’t count against the limit. Work that can’t start is retried for up to a minute. If no capacity frees up by then, the session doesn’t start, and Kana tells you every machine was busy so you can send the message again.