I used a bind mount to fix the biggest problem with Docker sandboxes

Built repro, which is a one-command to open any GitHub issue in a Docker sandbox:

pip install repro-cli
repro https://github.com/expressjs/express/issues/3860

First version cloned the repo inside the container. Worked great until I typed exit and lost everything I'd written. Container gone, files gone.

The fix was obvious in hindsight: don't let the container own the files.

host_dir = tempfile.mkdtemp(prefix=f"repro-{owner}-{repo}-{number}-")

args = [
    "docker", "run", "--rm",
    "-v", f"{host_dir}:/sandbox/{repo}",  # files live on host, not in container
    ...
]

Now the repo clones into a real folder on your disk. The container temporarily borrows access to it. When you exit, container dies, files stay.

This also solved the editor problem for free, VS Code can open that real folder and attach directly to the container via the Dev Containers extension, so its terminal runs inside the sandbox. One window, real editor, no split.

The one gotcha: if you're cloning a private repo, the token can't go in the clone URL (it'd end up in .git/config on your real disk in plaintext). So it goes via --env-file instead — a temp file with 0o600 permissions, deleted before you ever get a shell.

Repo: https://github.com/SukhdevThukral/repro

Curious to know what you'd have done differently.

Comments

[Alex Shev]

Bind mounts are one of those unglamorous fixes that make sandbox work usable. The important part is being explicit about what crosses the boundary: source, cache, artifacts, credentials, and anything that should stay read-only.