I'm a designer getting more into front-end development and still learning the security side. After reading about the keyv npm worm, I started using Docker Sandboxes so my coding agent runs inside a microVM rather than directly on my Mac. I also audited my setup even though I hadn't installed any of the affected packages.
I understand that a malicious package or install script running inside the sandbox should be isolated from unrelated files on my computer, and that the sandbox can be deleted afterward. However, my project directory is mounted into the sandbox, meaning it is the same folder on my real machine. If a compromised package writes malicious files into that directory, do those files remain on the host after the sandbox closes? What could happen if I later run the project outside the sandbox without noticing the changes?
I've also heard that malware could create something under .git/hooks and have it execute when I later use Git from the host. Is that a realistic concern? What other precautions should I take when using an AI coding agent in a microVM sandbox?
3 Answers
Yes—the mounted project folder is shared with the host, so changes made there are persistent. Closing or deleting the sandbox does not roll back files that were written into the mounted directory. The isolation mainly limits what the agent can access outside the project and helps contain processes while they are running.
A safer option is to clone or copy the repository into storage that belongs only to the sandbox, rather than bind-mounting your real working directory. If you do use a mounted folder, treat it as untrusted after the sandbox session and inspect or discard it before using it on the host.
The .git/hooks concern is legitimate. A malicious process could place a hook in the shared repository, and that file would still be present after the sandbox closes. It generally will not execute merely because the sandbox was shut down, but it could run later when a host-side Git command triggers that hook. Other project files, package scripts, editor tasks, and generated executables should be treated similarly.
Before running the project outside the sandbox, inspect the repository for unexpected changes—especially .git/hooks, package.json scripts, lockfiles, build scripts, and newly created executables. Using a disposable clone, avoiding host-side installs, keeping credentials and sensitive directories out of the mount, and reviewing the exact files changed by the agent are good habits.
If a malicious file is only sitting in the project directory and nothing on the host opens or executes it, it usually cannot do anything by itself. The danger starts when you run a script, install dependencies, invoke Git actions that trigger hooks, open a compromised tool, or otherwise cause the file to execute outside the sandbox. So deleting the sandbox helps, but it is not enough if the shared directory has already been modified.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures