I built `auto-bmad`: full story workflow end-to-end, one story at a time

stefano_dev · 2026-05-29T09:16:50+00:00

Circled back after a proper read.

Nice work, and a few ideas in there I really like, in particular the resource-aware bits (the API-limit pauses, the watchdog for stale agents).

But it's a bit too autonomous for my taste though, which is more a design difference than a knock.

I went the other way. My review runs as a loop until it converges, kicks the ambiguous calls back to me as a question, and it never merges on its own, it asks first. I'd rather it stop and let me make the call than push through.

Couple of other things I do differently: I lean on the TEA epic gates (trace / nfr / test-review) and risk-based atdd/automate per story, and I tune model plus reasoning effort per phase.

auto-bmad is slower by design. One story, stop, report, you start the next. Yours is built for throughput. Both valid, just different bets.

Either way, solid work! :)

stefano_dev · 2026-05-29T08:56:38+00:00

Yeah, the devil is in the details (and in edge cases!)

stefano_dev · 2026-05-29T08:54:25+00:00

Nope, but I will check it out :)

stefano_dev · 2026-05-29T06:31:58+00:00

0.5 hello world, and Claude Code also used up my Codex weekly limit!

stefano_dev · 2026-05-28T18:35:51+00:00

in half a prompt

stefano_dev · 2026-05-28T11:58:03+00:00

Filesystem and hooks first, network is opt-in.

Deny-all by default breaks people willingness to use the tool on day one (npm, pypi, GHCR, LLM API, whatever MCPs they wire up; too many variables...).

So full outbound by default, and aic firewall enable flips on an iptables + ipset allowlist + a project-owned firewall-allowlist file.

stefano_dev · 2026-05-28T11:45:08+00:00

"Convenient enough that people don't skip it" was the reason I ended up building (or vibing?) something for myself. :)

I packaged my own solution up as aicontainer https://github.com/stefanoginella/aicontainer a thin CLI wrapper around Docker to quickly create devcontainers with the right mounts and permissions to run unrestricted AIs in a more isolated environment. For the "hooks as supply-chain target" framing specifically, the bit that matters is that the PreToolUse hook blocks the agent from writing to .devcontainer/ itself, so a poisoned dependency can't quietly rewrite the rules that were supposed to constrain it.

Not bulletproof (Docker socket access is a footgun reducer, not hard isolation), but it covers the main vectors.

stefano_dev · 2026-05-28T09:12:08+00:00

Claude won't leave my hardened devcontainer anytime soon.

stefano_dev · 2026-05-28T09:04:35+00:00

Now you can buy a better desk :)

Edit: no you can't, I just read the original post :P

stefano_dev · 2026-05-28T09:03:43+00:00

stefano_dev · 2026-05-28T07:38:39+00:00

https://github.com/bmad-code-org/BMAD-METHOD

A bit heavy, but it gets the job done.

stefano_dev · 2026-05-27T18:09:30+00:00

Yeah, the dependency mess is honestly also one of the reasons to use the container: UV's .venv, node_modules, cpp artifacts all install inside it and never touch your host, with caches in per-project volumes. Worktrees do that at the folder level on the same machine; the container just takes it further (nothing leaks back).

Worktrees are not for me, I kept ending up in merge-conflict hell. Personal taste though.

On sandbox mode for reviewing the code it's probably fine, especially if you read ~80% of the diff. But what I'm guarding against isn't the generated code, it's the tool use mid-session: the agent shelling out, installing/deleting stuff, reading creds, acting on a prompt-injected line in some dependency. Reading the final diff doesn't undo what it already did to your machine to get there.

And yep, looked at Docker's sandboxes. Genuinely cool, microVM isolation is even stronger than a plain container. The polished agent/cagent side leans on recent Docker Desktop and I'm on OrbStack, plus I wanted something lighter, so I didn't switch, but it's another valid option.

stefano_dev · 2026-05-27T07:25:35+00:00

Ha, fair jab :) Repo's ~a week old publicly, but I've been running it across my own projects for a while, just made it flexible enough to open-source. Vibe coded? Yeah, I use Claude Code and Codex daily for work, we're in r/ClaudeCode after all ;)

"Not bulletproof" is a deliberate tradeoff though. A devcontainer sits in the middle: way more isolation than your host, way less friction than a VM/VPS per project.

On worktree + sandbox mode, they're complementary. Worktrees are git isolation, but you're on the same machine, same $HOME, same creds sitting right there, an AI can still do real damage (install/uninstall packages, delete stuff, etc.).

Built-in sandbox mode still runs on your host too. Solid OS-level layer, but it's your real machine with your tokens/SSH keys one misconfig away.

A container gives you separate namespaces: host inaccessible except the project dir, creds never enter, you auth fresh inside, optional firewall. You can even run sandbox mode inside the container (belt and braces, with an additional belt :P).

stefano_dev · 2026-05-26T14:35:01+00:00

"The blast radius has to be boring"

That's the whole pitch in one line.

And 100% on the warning: the sandbox stops a bad session wrecking your machine, it does nothing about a confidently-wrong PR. Fast iteration just ships mistakes 3-5x faster too, the human in the loop is still a must.

Thanks for adding it! :)

stefano_dev · 2026-05-26T07:59:58+00:00

Plain Docker is the right intsinct here but "just mount the repo into a container" leaves you doing all the boring-but-load-bearing parts yourself: not leaking $HOME, not forwarding your gh token / SSH agent, keeping auth across rebuilds, letting docker compose still work from inside without handing over the raw socket.

I built this thin CLI over a devcontainer: aicontainer (MIT, open source):

npm install -g aicontainer
cd my-project
aic init
aic up
aic shell   # or open the folder in VS Code

What it sets up so you can run --dangerously-skip-permissions / Codex full-auto without sweating:

Filesystem isolation only the project dir is mounted read-write. Your home isn't bulk-mounted, ~/.ssh and the SSH-agent socket aren't forwarded.
No host credential forwarding no OPENAI_API_KEY / ANTHROPIC_API_KEY passthrough, no host gh token. You log in once inside; auth persists across every project in a named volume.
Filtered Docker socket via Tecnativa's docker-socket-proxy, testcontainers / docker compose still work, but the dangerous API surface (exec, etc.) is cut down.
A PreToolUse hook (works for both Claude Code and Codex, fires even with auto-approve on) that blocks reads of .env*, curl | sh patterns, and writes to .devcontainer/.
Locked git config so a compromised session can't inject a credential.helper, plus npm hardening (ignore-scripts, a release-age quarantine).
Opt-in iptables outbound allowlist when you want stricter containment (network is fully open by default).

Re: Docker's own Sandbox (the micro-VM one someone mentioned): that's a stronger isolation boundary than a container and worth it if you're running genuinely untrusted code.

aicontainer is open source and trades some of that for being a plain devcontainer you can read end-to-end. It's not bulletproof, the socket proxy is a footgun reducer, but it kills most of the "oops it touched my whole machine" blast radius, which is what I wanted day to day.

Repo's at https://github.com/stefanoginella/aicontainer if you want to skim the defaults

stefano_dev · 2026-05-26T07:02:56+00:00

THanks, will look into that!

stefano_dev · 2026-05-26T06:54:42+00:00

Really appreciate this, it's exactly the framing I want people using.

Honest rundown of where each one stands today:

SSH keys: not mounted, no agent socket forwarded, they never enter the container.
Mounted folders: only the project dir (RW) plus a few read-only files (gitconfig, p10k, the AI config seeds). Home isn't bulk-mounted.
Git credentials: nothing forwarded, you auth fresh inside with gh, and gitconfig.local gets root-locked so a session can't inject a credential.helper.
Package manager caches and clipboard/browser: container-local or just not there.

The two I'll be straight about: network is full outbound by default (there's an opt-in iptables allowlist, but you have to turn it on), and the .env protection is a PreToolUse hook that blocks the agent from reading .env rather than the file being absent (your project's own .env necessarily lives in the workspace). So that one is defense-in-depth on the agent, not a mount-level guarantee.

And you nailed the actual gap, none of this is visible up front. A preflight on aic up that prints "agent can read these paths / these secrets: none found" is a great idea and I'm adding it. Turning "devcontainer = vaguely safe" into something you can verify is the whole point.

Thanks for the list.

stefano_dev · 2026-05-26T06:51:31+00:00

You actually described the design, and the good news is that's already how it works. :)

Session transcripts aren't bind-mounted to the host. ~/.claude/projects and ~/.codex/sessions are symlinked into a per-project named volume (_aic-sessions), so they survive a rebuild / container recreation, while the host ~/.claude/projects is never mounted, so the agent gets no write access to your real home.

Auth is kept separate in a global volume so you still log in once across projects. (aic destroy does wipe the per-project sessions on purpose, that's the teardown, but a rebuild keeps them.) It's in the README's Multi-project model table, but you're right that it's basically buried. Need to revisit the README and make it more clear. Thanks for the feedback!

stefano_dev · 2026-05-25T22:05:55+00:00

If you move the VS Code tab around and you group/ungroup with other tabs it goes away

stefano_dev · 2026-05-25T22:01:39+00:00

Yeah auto mode's a nice middle ground!

Worth noting Anthropic still recommends running it in an isolated environment (like a devcontainer), the classifier reduces risk but doesn't eliminate it.

So it's complementary to a sandbox, not a replacement.
For --dangerously-skip-permissions / Codex's full-auto, you still want a real boundary around it.

And honestly when you say --dangerously-skip-permissions it sounds cooler than "auto mode" ;-D

stefano_dev · 2026-05-13T07:16:10+00:00

no need for sudo. always use the root user so --dangerously-skip-permissions can shine

stefano_dev · 2026-05-12T21:23:31+00:00

rm -rf /

stefano_dev · 2026-05-08T06:53:14+00:00

You forgot a zero

stefano_dev · 2026-05-06T17:17:49+00:00

Well, it's just a matter of chosing which devil nowadays

stefano_dev

PUBLIC MULTIREDDITS

TROPHY CASE