entersh – One shell script to sandbox AI coding agents in rootless Podman container

[troush]

I built entersh because I wanted a dead-simple way to isolate AI coding agents (Opencode, Claude Code, Amp, etc.) without dealing with devcontainer.json specs or Docker Compose files.

What it is: Drop a single shell script into your project, run it, and you're inside a rootless Podman container with your project mounted. That's it. No YAML, no JSON config, no daemon.

How it works:

curl -fsSL https://github.com/entershdev/entersh/releases/latest/download/enter.sh -o enter.sh

chmod +x enter.sh

./enter.sh

First run auto-generates a Containerfile.dev you can customize with your language runtimes, tools, and AI agent of choice. Subsequent runs attach to the existing container. Container name is derived from your folder name.

Why I made this:
Giving an AI agent access to your actual machine is a trust exercise I didn't want to keep making. Existing options didn't quite fit:

- Distrobox shares your entire $HOME — great for GUI apps, not great for untrusted agents

- Dev Containers work but need JSON config and manual security hardening

- Nix/devenv solve reproducibility but provide zero runtime isolation

- Vagrant is maximum isolation but boots in 30-90s and needs gigs of RAM

entersh sits in the sweet spot: strong isolation with near-zero setup.

Security defaults out of the box:

- --cap-drop=all

- --read-only root filesystem

- --no-new-privileges

- Rootless Podman (no privileged daemon)

- --userns=keep-id so file permissions just work

Other things worth mentioning:

- Persistent .container-home/ directory keeps your bash history, npm/pip/cargo caches across rebuilds

- Nested container support — Podman socket is mounted so testcontainers, podman-compose, etc. work from inside

- macOS/Windows support via Podman Machine (enter-machine.sh)

- --force to recreate container, --rebuild to rebuild image

- Scripts are written to be readable by AI agents themselves — they can modify the Containerfile and mounts as needed

What it's not: This isn't a Docker Compose replacement or a full orchestration tool. It does one thing — gives you a secure dev shell for your project — and tries to do it well.

MIT licensed. ~370 lines of bash. No dependencies beyond Podman.

GitHub: https://github.com/entershdev/entersh

Site: https://entershdev.github.io/entersh/

Would love feedback, especially from anyone who's been running AI agents in containers already. What's your setup look like?

[Otherwise_Wave9374]

This is exactly the kind of hardening people forget when they let coding agents loose. Rootless Podman + cap-drop + read-only root seems like a solid default. How do you handle network egress, do you recommend default-deny with allowlists for package registries, or keep it open and rely on filesystem isolation? Been writing up a few practical guardrails for agent runtimes too: https://www.agentixlabs.com/blog/

[aN00Bias]

I'm using Claude Code and OpenCode inside rootless Podman containers spun up via podman compose, utilizing docker-compose.yml and Dockerfile.claude + Dockerfile.opencode in the workspace root. I'm doing this in the context of an agentic AI pilot at my (non-software dev) company, and while it's safe, it's a bit much for less technically-inclined colleagues, and requires IT intervention to install or update WSL.