What an agent can touch today
When you let an agent run npm install, pytest or make, it runs them the way you would: as your user, in your shell. Those commands can read and write anything your account can.
That includes the project, but also your home folder, your SSH and cloud config, your shell profile, the other repos next to this one, and any global package or tool on your PATH.
Good agents are careful. OmniRush, for example, asks before git writes, destructive commands and sudo. But asking only helps when the command looks dangerous, and many risky commands look routine.
Asking only helps when the command looks dangerous, and many risky commands look routine.
The realistic risks are boring ones
The scary scenario is an agent going rogue. The likely one is an ordinary command doing ordinary damage:
- A cleanup in the wrong place. rm -rf build is fine in the project and less fine one folder up.
- Global installs. An agent fixing one project upgrades a global tool or a system Python package, and another project stops building.
- Install scripts. Package managers run scripts from dependencies at install time. The agent did not write them and neither did you.
- Leftovers. Background servers, changed config files and caches that outlive the task.
- Reading more than it needs. An agent searching for a config file can wander into folders that have nothing to do with the task.
None of these need bad intent. They are what happens when any fast, tireless worker runs hundreds of commands a day on a real machine.
$ omnirush
# the agent's commands run as you:
# your home folder, your global tools,
# your other projects, your config$ omnirush sandbox on
$ omnirush
# the agent's commands run in a Linux
# sandbox kept for this project;
# your files and chats stay where they areWhat a sandbox changes
A sandbox gives the agent's commands their own environment, separate from the rest of your machine. Installs land there, tools run there, and most of what goes wrong stays there; the project folder itself is still your files.
There is a second benefit people notice less: a sandbox is a clean, Linux environment per project. A project set up there is set up the same way every time, without the leftovers from three other projects on your laptop.
And the trade-off: a sandbox adds a moving part. It needs a sandbox tool on your machine, and on macOS and Windows that means a Linux environment, which is not the same as your own system. That is why the details below matter.
How OmniRush does it
OmniRush has an optional Linux sandbox for each project folder. When it is on, the agent's commands run inside the sandbox, while the app, your chats and your files stay on your machine.
$ omnirush sandbox on # this folder uses the sandbox from now on
$ omnirush --sandbox # or only this run
$ omnirush sandbox status # which tool is used, and why
$ omnirush sandbox off # back to running on your machineomnirush sandbox status shows which tool is used and why; add --details for the full output. omnirush sandbox setup walks through the setup with one clear next step for your OS when a runtime is missing.
It uses the tool your computer already has
| System | Sandbox tools |
|---|---|
| Linux | bubblewrap, Podman or Docker. bubblewrap ships in OmniRush's Linux packages, so most machines need nothing extra |
| macOS | Container tools: OrbStack, colima, Docker Desktop, Rancher Desktop or Podman, or Apple's container when you pick it |
| Windows | WSL containers, OmniRush's own WSL image, Docker Desktop or Podman |
You can also pick the tool yourself with omnirush sandbox backend, or --sandbox-backend for one run. A tool you picked that cannot run stops the run with a clear message, instead of quietly running on your machine. On automatic, if no sandbox tool is available at all, the run carries on directly on your machine with a one-line note.
Installs stay, so it is not slow
A sandbox that starts from zero every time would mean reinstalling dependencies on every run. OmniRush keeps one sandbox per project: packages the agent installs are still there next time. If the sandbox stops while the app is open, after a long idle time or a crash, it reconnects, and the installs are kept.
Git still knows who you are
Git works inside the sandbox with your own name and email, so commits the agent makes for you look like yours.
Packages the agent installs are still there next time.
On by default? It depends
The sandbox may be on by default for new chats, depending on your system and OmniRush's current settings. Your existing chats keep running as they were when it is turned on for you; new chats get the sandbox. omnirush sandbox status always tells you what is in force, and a folder's omnirush sandbox off wins.
macOS and Windows: existing builds keep working
The sandbox is Linux. A project that already has builds for your Mac or Windows machine, such as a node_modules folder, a Python virtual environment or compiled programs, would break if it suddenly ran on Linux. So on macOS and Windows those projects keep running natively, and clean projects run in the sandbox. Chats in the sandbox on those systems say so in one line, with how to switch it off.
Sandbox, permissions and git: use all three
A sandbox is one layer, not the whole answer. The setup we would recommend for any agent:
- Keep the project under git and commit before a big task. Any change is then one git diff away from review and one git restore away from gone.
- Keep the agent's guard on for unfamiliar projects. In OmniRush that is the default: git writes, destructive commands and sudo ask first.
- Turn the sandbox on for projects where the agent installs things or runs code you did not write.
- Only then consider --yolo, or full permissions in the desktop app, which let every command run without asking. Inside the sandbox, that trade is much easier to justify.
- Keep secrets out of the folder. A sandbox limits what commands can reach, but anything in the project is part of the project.
When you do not need it
For a quick question about a single file, a one-shot review of a diff, or a project with no dependencies to install, running natively is fine and a little faster to start. The sandbox earns its keep on projects with installs, build steps, test suites and code you did not write, which is most real work.
Try it
Install the CLI with npm i -g omnirush@latest (Node.js 22.19 or newer), sign in with omnirush login, then run omnirush --sandbox in a project folder. In the desktop app, the sandbox is in Settings. Sign-up needs a GitHub account at least 7 days old.
OmniRush is funded by brand ads, and data use described in its privacy policy.
Questions
Does OmniRush run the agent in a sandbox?
It can. Each project folder can have its own Linux sandbox: omnirush sandbox on for the folder, or omnirush --sandbox for one run. It may be on by default for new chats, depending on your system and settings; omnirush sandbox status shows what is in force.
What does the sandbox need on Linux?
bubblewrap, Podman or Docker. bubblewrap ships in OmniRush's Linux packages. On Ubuntu 23.10 and newer, run sudo omnirush sandbox enable once.
Does the sandbox work on macOS and Windows?
Yes, through container tools on macOS and WSL or container tools on Windows, including OmniRush's own WSL image. Projects that already have builds for your machine keep running natively.
