entersh — Dev containers for AI coding agents

Quick start

Linux

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

macOS / Windows (WSL2)

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

On first run, a default Containerfile.dev is generated. Add your project env and agent:

# Add your language/runtime
RUN dnf install -y golang nodejs python3 ...

# Install your AI coding agent
RUN npm install -g @anthropic-ai/claude-code   # Claude Code
# RUN curl -fsSL https://opencode.ai/install | bash  # Opencode
# RUN npm install -g @anthropic-ai/amp               # Amp

Then rebuild: ./enter.sh --rebuild

Why containers for agents?

Isolation — agents can't damage your host. If something breaks, destroy and recreate.
Reproducibility — same environment everywhere. The Containerfile is the source of truth.
Simplicity — one script, not a platform. No Docker Compose, no Kubernetes.

Why Podman?

Rootless by default — no daemon running as root, no Docker Desktop license issues.
File permissions work — --userns=keep-id maps your UID into the container.
Daemonless — each container is its own process.
Nested containers — run podman, testcontainers, or podman-compose from inside the container. No Docker-in-Docker hacks.

entersh requires Podman. It is not Docker-compatible.

Why entersh?

entersh is designed for one thing: giving AI coding agents a safe, reproducible place to work. It's a single shell script you drop into a project — no config language to learn, no platform to install, no YAML to maintain. The folder name is the container name. First run generates a Containerfile.dev if you don't have one. Security hardening is on by default (--cap-drop=all, --read-only, --no-new-privileges). That's it.

Tool	Approach	Agent isolation	Config complexity	Nested containers
entersh	Rootless Podman container	Strong (secure defaults)	Zero config (one script)	Yes (Podman socket)
Distrobox	Host-integrated container	None (shares $HOME)	Minimal	Via host-exec
Dev Containers	Docker container + JSON spec	Good (needs hardening)	Medium (devcontainer.json)	Yes (DinD feature)
Docker Compose	Multi-container orchestration	Moderate	Medium (compose.yaml)	Requires privileges
devenv	Nix shell environments	None (no container)	Medium (Nix language)	N/A
Vagrant	Full VM	Strongest	Medium (Vagrantfile)	Yes (full kernel)

Distrobox shares your entire $HOME by design — great for GUI apps, wrong for untrusted agents.
Dev Containers are the closest alternative but require a JSON spec, a supporting editor/CLI, and manual security hardening.
Docker Compose is a service orchestrator, not a dev environment tool — you build the sandbox yourself.
devenv/Nix solve reproducibility brilliantly but provide zero runtime isolation.
Vagrant has the strongest isolation (full VM) but boots in 30-90s and needs gigabytes of RAM.

How it works

Drop enter.sh into your project
Run it — a Containerfile.dev is generated if one doesn't exist
The image is built and a container is created automatically
On subsequent runs, it attaches to the existing container
Use --force to recreate, --rebuild to rebuild the image, --verbose for full output

The container name matches your project folder name.

Agent-first by design

The scripts are written to be read and modified by AI coding agents. Every section has comments explaining what it does and how to extend it. Just ask your agent to update enter.sh and Containerfile.dev for your project — it will know what to do.