Write-Confining Sandboxes on Three Operating Systems
When an agent runs a command on your machine, something has to decide what that command may touch. Atlarix confines agent commands so they can write only inside your workspace and the paths you have granted, while still reading and executing normally. That sounds like one feature. It is three, because macOS, Linux and Windows offer nothing in common, and the Windows one took two attempts.
What the sandbox is actually for
The threat is not a hostile user. It is an agent that has misread the task and is confidently doing the wrong thing — a rm aimed one directory too high, a build script that writes into a sibling project, an installer that decides your home directory needs reorganising.
So the policy is narrow on purpose: writes are confined to the workspace plus granted paths, while reads and execution stay unrestricted and the network stays on. Confining reads would break the toolchain immediately, and an agent that cannot read your dependencies cannot do the job.
macOS and Linux
On macOS the mechanism is Seatbelt, through sandbox-exec. The profile is generated per command from the workspace root and whatever paths have been granted for that turn.
On Linux it is Landlock, through a small bundled helper. Where the kernel is too old or Landlock is unavailable, it falls back to bubblewrap if that is installed. Both platforms had the advantage of a native primitive that does roughly what we wanted, which is not the situation Windows presented.
The Windows attempt that failed
The first Windows implementation used AppContainer, which is the modern, documented, correct-sounding answer. It was written, it compiled, it passed review, and then it was executed on real hardware and broke the toolchain outright.
bash.exe returned Access is denied. Git failed with could not open '/dev/null'. PowerShell's FileSystem provider stopped working. The diagnosis mattered more than the symptoms: git had actually *executed* and exited 128, so this was not a file-permission problem at all. AppContainer was isolating the device and object namespaces, which is not something you can fix per path.
What Windows ships now
The rewrite on 2026-08-07 moved to Low Integrity Level, which is a different primitive with the polarity we needed. The process runs as the same user with a lower integrity label, so it reads everything it could before, and only writes *up* to higher-integrity objects are refused.
Writes back into the workspace are granted by stamping a Low mandatory label onto each writable root. That is the honest cost of the approach, and it is worth stating: the label is persistent, not reverted per command, so another Low-integrity process running as the same user could write there too.
Three limits we would rather state than have discovered
The sandbox covers agent `run_command` only. Your own interactive terminal tabs are never sandboxed, and file edits go through a different path entirely — the approval queue, where you see the diff before anything is written.
Browser and mobile tooling do not go through it either; those are constrained by a tool-level deny ruleset instead. And it degrades gracefully by design: on a machine where the mechanism is missing, the command runs unsandboxed rather than failing. A read-only mode is therefore a best-effort OS guarantee, not an absolute one.
What the AppContainer failure taught us
The lesson was not "test on real hardware", though that is true and we did not. It was that a security primitive has a polarity, and choosing one by reputation rather than by shape is how you end up rewriting it.
AppContainer is deny-by-default on reads. We wanted deny-by-default on writes. Those are not the same primitive pointed in two directions; they are different mechanisms, and no amount of per-path configuration converts one into the other. We had picked the well-regarded option instead of the one that matched the policy.
Three operating systems, three mechanisms, one policy — and one public rewrite because the first Windows answer was the reputable one rather than the right one. The sandbox is smaller than it sounds and we would rather say so than let you assume it covers work it does not.