Gap Hunter Labs
ghl-jail
A one-line Windows sandbox for the command-line tools you don’t fully trust. It runs a command with access to a single project folder — and nothing else of yours. No administrator rights, no driver, no install.
The problem
In April 2026 a malicious build of the Bitwarden CLI was live on npm for about ninety minutes. In that window it read SSH keys, .env files and AWS, Azure and GCP credentials off every machine that installed it. In October, the official OVHcloud CLI’s repository was briefly compromised the same way — a bad build, caught and blocked in 94 minutes, but only after a customer noticed.
Neither was a virus you could have spotted. Antivirus asks whether a file is known to be bad and waves through anything new. And every CLI you run — a package manager, a release binary, a script a teammate sent you — runs as you, with full read access to ~/.ssh, your cloud credential files, your browser profile and any token sitting in your environment.
Why the usual isolation is too heavy
Spin up a VM or a container just to try one throwaway tool, and you pay for it in minutes and gigabytes — and on Windows the solid isolation options want Pro, Hyper-V, or an admin you may not have on a locked-down work machine. So in practice most developers isolate nothing. The tool just runs.
A fence in one line
ghl-jail runs a single command so it can only touch the one project folder you point it at:
Inside that folder the tool reads and writes freely. The moment it reaches outside — for ~/.ssh, a cloud credential file, a token in your environment — it hits a wall:
And by default it has no network, so even a tool that found nothing to read has nowhere to send it.
What it blocks and allows
ghl-jail has two modes. Container is the tightest — walled off from the whole machine except the project folder, with no network. Token is for tools that need the network or that won’t start under the tightest mode (git); it still blocks your profile. An auto mode picks container for everything and quietly switches to token only for the few tools that need it, telling you when it does.
| The tool tries to… | container | token |
|---|---|---|
| read / write your project folder | allowed | allowed |
read ~/.ssh, ~/.aws, .env, browser data, the rest of your profile | blocked | blocked |
| write anywhere outside the project | blocked | blocked |
| reach the network | blocked (unless asked) | allowed |
| read an API token left in an environment variable | blocked | blocked |
| run python, java, node | yes | yes |
| run git | no (Windows quirk) | yes |
Three ways to use it
Try an untrusted or just-downloaded CLI
It sees an empty folder and no network — a backdoored build like the Bitwarden case finds no credentials on disk and no way out.
Keep an AI coding agent inside one repo
An AI agent, or any autonomous script, that edits code and runs commands reads and writes only that repo, offline unless you allow it. The blast radius of a confused or prompt-injected run becomes one repo you can git reset, not your whole account.
Run npm install / pip install without ceding your credentials
Install scripts reach the registry and write into the project, but a malicious post-install hook — exactly the Bitwarden pattern — never sees your SSH keys or your real tokens.
What it is not
It is harm reduction, not a vault. It raises the cost of a mistake a great deal; it is not a guarantee against an attacker who is actively targeting this specific sandbox, and it does not replace kernel-level enforcement or a real VM. It is the fence you put around a tool before you trust it — not a reason to run things you already know are malicious.
Get it
You need Python 3.8+ and Windows 10 or 11 (Home included). No administrator rights, no install, no background service. Clone the repository and run it:
Open source and free. Windows only. The README has the full walkthrough, the three modes and the known limitations.