I'm a designer learning front-end development and trying to understand the security boundaries of Docker Sandboxes. After reading about a malicious npm worm, I started running my coding agent inside a microVM instead of directly on my Mac.
My understanding is that if a package's install script is malicious, it runs inside the sandbox and is isolated from the rest of my computer. However, my project directory is mounted into the sandbox, meaning it is the same directory on my host machine. If a compromised package creates or modifies files there, those changes would still exist after the sandbox is closed, right? What could happen if I later run the project outside the sandbox without reviewing it first?
I've also heard that a malicious package could add something under .git/hooks, such as a hook that runs during a normal Git operation. Is that a realistic risk, and what should I check? What other precautions would you recommend when using a coding agent this way?
3 Answers
The key distinction is between the sandbox’s virtual machine boundary and the files you deliberately share with it. The microVM can limit what the agent reaches outside the project, but anything written through the mount is an intentional path back to your real filesystem. Container or microVM isolation also should not be treated as an absolute guarantee against every possible escape or host-side mistake.
For higher-risk experiments, use a fresh disposable checkout, avoid mounting sensitive directories, keep credentials and SSH keys unavailable, and only copy reviewed source files back to your main workspace. Running the agent as a user with limited permissions and keeping backups or version control available also makes recovery easier.
Yes—the mounted project directory is shared with the host, so files created or changed there generally remain after the sandbox shuts down. The sandbox protects the rest of your machine from the agent while it is running, but it does not automatically clean or revert changes made in a bind-mounted folder.
That means you should treat the project directory as potentially untrusted afterward. Don’t immediately run its scripts, binaries, or development tools on the host. Review the changes first, and if the project is disposable, deleting it and cloning a clean copy is often the safest option. A separate clone copied into the sandbox, without mounting the host working tree, gives stronger isolation, though you’ll need another way to transfer approved changes back out.
The .git/hooks concern is legitimate. A process inside the sandbox could write a hook into the mounted repository, and that file would still be present on the host after the sandbox closes. It normally won’t execute merely because the sandbox was closed, but it could run later when a host-side Git command triggers that hook.
Before using the project outside the sandbox, inspect .git/hooks, package.json scripts, lockfiles, and any newly created executable or shell files. Also be careful with commands such as npm install, npm run, build tools, and scripts that execute automatically during package installation or Git operations. Keeping untrusted work in a disposable clone and avoiding host-side execution until it has been reviewed reduces the risk considerably.
So closing the sandbox is not enough by itself—the modified files are still on the mounted folder. If I never run the project or trigger Git hooks on the host, a malicious hook should not execute on its own, but I should still inspect or discard the directory before using it normally.