Guide: Setting up a sandbox to safely test its potentially dangerous shell commands.

Hello everyone! I’ve been seeing a lot of discussion about assistants generating shell commands that *look* correct but could wreak havoc if run without a safety net. I think we can all agree that the most dangerous failures are the ones that sound perfectly reasonable until you’re staring at a broken production environment or deleted files. 😅

Over the years, I’ve refined a setup for a disposable, isolated sandbox specifically for vetting these command suggestions. It’s saved me countless times, especially when testing automation scripts or deployment steps an assistant might propose. I wanted to share my workflow here, as a concrete example of a reproducible safety practice.

**The Core Idea:** Create a temporary, containerized Linux environment that you can spin up, test in, and destroy without a trace. I use Docker because it’s ubiquitous and quick.

**My Standard Sandbox Setup:**

* **Base Image:** I always start with a fresh `ubuntu:latest` or `alpine:latest` container. It’s clean and has no ties to my system.
* **Persistent Test Directory:** I mount a temporary local folder into the container at `/test`. This lets me stage mock files, configs, or dummy data for the commands to act upon.
* **Non-Root User:** I immediately create and switch to a non-root user inside the container. This better mimics a real environment and limits some (but not all) damage.
* **Network Isolation:** The container runs without special network privileges unless the command specifically needs internet access for testing.

**A Typical Test Session Looks Like This:**

1. I create a temporary directory on my host: `mkdir -p /tmp/sandbox_test && cd /tmp/sandbox_test`
2. I populate it with any dummy files or folder structures relevant to the assistant’s prompt.
3. I launch the sandbox container with:
```
docker run -it --rm
--name cmd_sandbox
--network none
-v /tmp/sandbox_test:/test:rw
ubuntu:latest /bin/bash
```
4. Inside the container, I set up the non-root user:
```
useradd -m tester
chown -R tester:tester /test
su tester
cd /test
```
5. Now I’m in a safe, isolated environment. I can copy/paste the assistant’s suggested shell command sequence here and observe exactly what it does—what files it creates, modifies, or deletes, and whether it errors.

**Why This Catches Failures:**
* **Hallucinated Tools or Flags:** If the assistant suggests `apt install non-existent-package` or uses a `--flag-that-doesnt-exist`, it fails immediately inside the clean container.
* **Dangerous Path Assumptions:** Commands with absolute paths like `rm -rf /usr/lib/*` will only affect the container’s isolated filesystem.
* **Broken Multi-Step Sequences:** You can run the steps one-by-one and see where the logic falls apart, like a `git` operation that assumes a repo is already initialized.

The key is to never, ever run a suggested shell command from an assistant directly in your own terminal or CI/CD pipeline without first replaying it in a sacrificial environment like this. It adds maybe two minutes to your workflow but prevents catastrophic "oops" moments.

I’d love to hear how others are setting up their safety nets! Do you use VMs, a dedicated physical machine, or a different container approach?

—Hannah