Grux OS snapshots the project into a shadow git repository before each command runs, so any command the agent issued can be reversed afterwards without touching your own git history or your own commits. That is the whole approach: make the work undoable rather than make the agent cautious. The failure everyone pictures is an agent running one destructive command, but the failure that actually happens is smaller and worse, a sequence of plausible commands that leaves a working tree you cannot reconstruct, and caution does not catch that. On top of the snapshot sit three cheaper guards: commands run only inside folders you chose, a denylist refuses the categories that end badly, and anything that reaches the network, deletes a file or spends money stops in an approvals queue until you press the button.
| Layer | What it stops | What it costs you |
|---|---|---|
| Path allowlist | Work outside the folders you picked | Nothing. Out of the box the list is empty |
| Command denylist | The categories that end badly | Occasionally a command you meant |
| Approvals queue | Network, deletion and spend, until you agree | One button press |
| Shadow git snapshot | Everything else, after the fact | Disk, and nothing else |
The ordering is the point. The first three try to prevent, and prevention is always incomplete because a shell is a general purpose machine. The fourth does not try to predict anything, which is why it is the one that catches the failure nobody wrote a rule for.
Snapshotting into your own git history would mean the agent writes commits, and then undo means rewriting history you might have pushed. A separate shadow repository keeps the agent's before-state entirely out of your log, so your branches, your staged changes and your commits are exactly where you left them whether you undo or not.
It sits there until you act. Approvals is core rather than Labs, and it declares no capabilities at all, so it is ready on a clean install and simply shows an empty queue.
Shell execution and file reading are different paths with different guards. The model's only route to your disk is one Swift file, and it enforces a read-only allowlist, a denylist covering .ssh, .aws, .env, your Keychains, Mail, Messages and browser profiles, a size cap, a rate limit, a secret pattern scan on everything it returns, and an audit log that records refusals as well as reads.
{"bytes":0,"outcome":"denied_denylist","path":"~/.ssh/id_ed25519","reason":".ssh",
"resolved":"/Users/you/.ssh/id_ed25519","tool":"fs_read","ts":"2026-08-25T14:02:11Z"}Grux OS is not sandboxed, because screen capture, AppleEvents and cross-app microphone access do not exist inside the App Sandbox. The boundary is a Swift file rather than the operating system, which means a defect in that file is a real hole. The trade is written up in the repository's SECURITY.md, including the parts it does not cover.
| Claim | Source |
|---|---|
| Grux OS snapshots the project into a shadow git repository before each command runs | ShellSnapshotStore.swift |
| Each command is locked to the session's working folder, with escape patterns pre-scanned | ShellSafety.swift |
| The folder allowlist is empty until you choose a folder in Settings | FilesystemTool.swift |
| A denylist covers .ssh, .aws, .env, Keychains, Mail, Messages and browser profiles | FilesystemTool.swift |
| Network, deletion and spend stop in an approvals queue until you agree | WorkOrder.swift |
| Grux OS is not sandboxed; screen capture and AppleEvents need the sandbox off | SECURITY.md |