Exploring the Sandbox

Reattach to the sandbox
The filesystem: workspace vs everything else
Who and what you're running as
Installed tools and environment variables
Processes
Networking and what the sandbox can reach
Proving the isolation
Beginner Pitfalls

1. Reattach to the sandbox

If you're starting a new terminal session, get back into the sandbox from Part 2 first:

sbx run --name sbx-crash-course

Everything below runs inside that shell, not on your host.

2. The filesystem: workspace vs everything else

pwd
ls -la

You'll see the files from the host directory you started sbx run in — that one directory is your workspace, mounted through so both sides see the same files instantly, no syncing. Now look around outside it:

ls /
ls /home

This is the sandbox's own root filesystem — its own /etc, its own /var, its own package cache — not your host's. Anything you install or create outside the workspace lives only inside this sandbox and disappears when you sbx rm it.

3. Who and what you're running as

whoami
uname -a
cat /etc/os-release

You're a regular user with sudo access (Docker Sandboxes gives the shell sudo so you can install packages and manage its Docker daemon), on a Linux kernel that belongs to this microVM — not your host's kernel, even if you're on macOS or Windows.

4. Installed tools and environment variables

which docker git curl node python3
env

The shell base image comes with a common baseline of dev tools already installed. env shows the sandbox's own environment — separate from your host's shell environment, unless you explicitly passed variables in with sbx run -e or --env-file.

Note: -e/--env on sbx run only takes effect for the agent/shell session that command starts. To make a variable available every time you reattach, append an export to /etc/sandbox-persistent.sh — see sbx usage docs for the exact recipe.

5. Processes

ps aux

This lists only the processes running inside the sandbox. Your host's processes — your browser, your IDE, whatever else is running on your machine — are completely invisible from here, and vice versa: nothing you start inside the sandbox shows up in your host's process list or task manager.

6. Networking and what the sandbox can reach

curl -I https://registry.npmjs.org
curl -I https://example.com

Under the Balanced policy you picked in Part 2, common package registries and dev services are allowed; most everything else is blocked by default. Check what's actually configured:

sbx policy ls

(Run that one from your host terminal, not inside the sandbox — sbx policy manages the sandbox from the outside.)

7. Proving the isolation

A few quick checks that make the three layers from Part 1 concrete:

Try this	Where to run it	What it proves
`docker ps` on your host	Host terminal	The sandbox's containers (once you have some, from Part 5 onward) never show up here — separate daemon entirely.
`ls ~` inside the sandbox	Sandbox shell	Only the workspace directory looks like your host; the rest of the home directory is the sandbox's own.
`curl http://host.docker.internal:PORT` for something running on your host	Sandbox shell	Reaches your host only through this special hostname — never a plain `127.0.0.1` or your machine's LAN IP, which aren't reachable from inside the sandbox at all.

That last one is worth remembering — it comes back in Part 6 and Part 7.

8. Beginner Pitfalls

127.0.0.1 inside the sandbox is the sandbox's loopback, not your host's. If something running on your host needs to be reached from inside the sandbox, use host.docker.internal, not 127.0.0.1 or your host's LAN IP.
Don't expect docker ps on your host to show anything you start inside the sandbox. They're genuinely separate daemons — that's the whole point.
If a curl to some API fails from inside the sandbox, it's very likely the network policy (Balanced blocks by default, allows a known list), not a real connectivity problem. Part 7 covers the fix.