Security model

When an agent picks up a run, the daemon spawns an AI coding tool (Codex, Claude Code, and so on) as a child process. Understanding what that process can touch is the whole security model.

The boundary is the daemon user

By default a run executes with the full permissions of the operating-system user running the daemon. It can read and write every file that user can, use that user's credentials, and reach the network without restriction.

Multica makes no filesystem-sandbox guarantee. One narrow exception exists today — Windows, where you have explicitly opted into Codex's native sandbox — but which platform and configuration combinations sandbox anything is a compatibility detail that moves with tool versions. Treat every run as unsandboxed and put the boundary outside the daemon.

This is deliberate. Agents are asked to install dependencies, run builds, use your cloud CLIs, and drive tooling that expects a normal home directory. A partial filesystem sandbox breaks that work in ways that are hard to diagnose — the tool reports "not logged in" or silently uses the wrong account — while still not protecting the thing that matters most, since it cannot stop a run from reading credentials and sending them over the network.

So Multica does not pretend to be the boundary. Put one around it.

Recommended setups

Pick whichever fits your infrastructure — they are listed from lightest to strongest:

1. Dedicated Unix user. Create a multica user, give it only the repositories and credentials the agents need, and run the daemon as that user. Your own account stays untouched.
2. Container. Run the daemon in a container with only the mounts and secrets the agents need.
3. Virtual machine. Full isolation, at the cost of provisioning a machine.

Whichever you choose, treat the credentials reachable from that environment as credentials the agent may use: scope tokens narrowly, prefer per-purpose deploy keys over your personal SSH key, and avoid leaving unrelated production credentials in that user's home directory.

What Multica does isolate

These are real, but they are conveniences and blast-radius reduction — not a security boundary against a run that actively tries to escape:

• Per-run working directory. Each run gets its own workdir under ~/multica_workspaces/, so concurrent runs do not collide on the same checkout.
• Per-run agent state. Codex runs get a run-scoped CODEX_HOME holding config, sessions, and skills, so per-run settings do not pollute your ~/.codex/.
• Run-scoped API tokens. The MULTICA_TOKEN handed to a run is bound to that agent and that run by the server, so a run cannot act as you or as another agent through the Multica API.

What is not a boundary

• The coding tool's own sandbox and approval settings. Multica runs agents unattended, so approval prompts are answered automatically. On the default path the filesystem sandbox is off as well: Codex runs with sandbox_mode = "danger-full-access" and Claude Code with --permission-mode bypassPermissions. The exception is Windows — if you explicitly configure Codex's native sandbox (windows.sandbox = "unelevated" or "elevated"), Multica honors that opt-in and keeps workspace-write for those runs. Worth doing where it fits, but it is one tool on one platform and it does not change how you should scope the daemon user.
• Your HOME directory layout. Runs inherit the daemon user's real HOME and XDG_* variables, which is what makes host CLIs (gh, aws, kubectl, gcloud, glab) work inside a run exactly as they do in your shell. It also means everything under that home is reachable.

Checking what a run ran with

The daemon logs the effective sandbox mode at warn level when a run starts unsandboxed:

multica daemon logs --lines 200 | grep "codex sandbox"

To confirm the effective Codex configuration, read the managed block in the run's config.toml under the run's CODEX_HOME — the section between the # BEGIN multica-managed and # END multica-managed markers is written by the daemon on every run.