Docker can help with all of this, so I thought up a workflow and used some shell aliases to automate spawning Claude/Codex agents into docker containers. I ended up creating a cli to wrap all these methods and would like to share it.
The problems agentspace is solving:
- You can run many tasks in parallel all working on their isolated copy of the code.
- No death by tapping y. You work on an isolated copy of your code in a fairly safe environment always so it becomes easy to get out of the way and just let the agent do its thing without potentially compromising your machine. Agents spawned by agentspace run containerized in yolo mode by default.
- No multiplexers. I have never had a use case for them so I am not used to them at all. The container is just a normal shell. Detach with Ctrl-P Ctrl-Q (standard Docker), reattach with `agentspace my-task attach`. No new muscle memory required.
- No git worktrees either. All approaches using this to run parallel agents just never stuck with me.
- Sessions typically die on SSH disconnect. Containers always keep running. Reconnect whenever you want.
I am now using this daily for running my agent sessions both on my own machine as well as on a remote VM.
Features:
- Spawn many agents which all run in parallel and work on their own code by mounting a volume to a docker container
- Preview results with a dedicated preview command which launches a container attached to the same volume so you can preview changes in real time
- Docker support inside the container via a docker-in-docker sidecar (Please note: `--docker` uses `--privileged` under the hood (required for DinD), so it's not a sandbox against actively hostile code. Use it for repos you'd trust on your machine anyway.)
- You handle the git commit, push etc. cycle so you stay in control of what goes into your repo. This is enforced at the image level via `PreToolUse` hooks for Claude Code and exec policy rules for Codex, so it holds even under `--dangerously-skip-permissions`. I don't like agents running changes for me, so I want to be in control here
Once pushed, it's just a normal branch so you can merge it through your usual PR flow. It does require a git remote though at the moment as this is the only way to get the work out of the container via the agentspace cli (of course you can use any direct docker command as well).
Current limitations:
- Base image is `node:24-slim`. Node/TypeScript works out of the box, other runtimes need you to extend the image yourself (You can create your own Dockerfile from agentspace and point `AGENTSPACE_IMAGE` at it). I am planning to just include more languages and runtimes in the agentspace base container as well, but so far this works for me.
- Supports Claude Code and Codex today. I would like to support Opencode and Pi later
- Windows unverified (should work as this project basically only needs node, git and docker, but it hasn't been tested)
- Some parts lightly tested or untested. I basically built it last week to scratch my own itch. It has some rough edges for sure. Very curious to get other experiences.
figmert•55m ago
> - Docker support inside the container via a docker-in-docker sidecar (Please note: `--docker` uses `--privileged` under the hood (required for DinD), so it's not a sandbox against actively hostile code. Use it for repos you'd trust on your machine anyway.)
These statements are pretty contradictory. If dind has privileged access, then that means the agent has essentially root access (or access of the host user if rootless)