[QUESTION] Is it meant to be used as just a terminal for CC while we do everything else outside the devcontainer?

[rpgdev]

Wondering if you could you give some insight into how to use the devcontainer that the script sets up? Is it meant to be used as just a terminal for CC while we do everything else, like running framework-specific utilities, outside the devcontainer? Or are we meant to install everything that isn't already included manually from inside the container, or are we meant to modify the devcontainer definition that the script installs? I just want to be sure I'm not trying to force a use case onto it that it isn't meant to solve and end up fighting the tool out of ignorance. Your script did solve the issue of trivially setting up a devcontainer for my project and using Claude in Yolo mode without having to risk too much of my system, so thanks for that. The official devcontainer setup was a pain to get to recognize my account.

[engyii]

After reading the README more carefully, my understanding is that the intended workflow is:

The container IS the dev environment — you open a shell with devc shell or use VS Code/Cursor's "Reopen in Container" to work entirely inside it, not just for Claude.
The goal is not to have a perfect pre-configured env, but to give Claude a sandboxed space to run with bypassPermissions safely.

That said, I'm also unsure whether the expected workflow involves customizing the .devcontainer/ files per-project, especially on a complex mono-repo with a lot of moving parts...

[rpgdev]

Fwiw, I fed it to Claude via gitingest and asked around and this is what I got:

Based on the project's design, you're meant to do your work inside the container. It's not just a terminal wrapper around Claude Code — it's a full development environment.

The container comes with a substantial toolchain already installed (Node.js 22, Python 3.13, ripgrep, fd, tmux, fzf, build-essential, etc.), and you're expected to install whatever else you need inside it. The vscode user has passwordless sudo, so installing additional tools is straightforward.

A few design choices make this clear:

The workspace mount binds your project directory into /workspace inside the container, so you're editing real files — not copies. The persistent volumes for shell history, Claude config, and GitHub CLI auth survive container rebuilds, meaning the container is intended to be your ongoing working environment, not something ephemeral. The VS Code/Cursor integration with the Dev Containers extension gives you a full IDE experience inside the container, not just a terminal.

The Pattern B (Shared Workspace) workflow especially reinforces this — you create a workspace directory, spin up the container, then clone repos and do all your work from inside it.

So yes, you'd install any other project dependencies inside the container. That's actually part of the safety model: anything you install or run stays contained. If something goes wrong, you rebuild the container and your host is untouched.

There's no mechanism in the project for Claude Code to automatically detect and install project dependencies or additional tools like Wails.

What it provides is a base environment with common dev tools pre-baked into the Dockerfile, plus the post-install script that configures Claude settings, tmux, git, and directory ownership. But beyond that baseline, you're on your own to install whatever your specific project needs.

You could extend it yourself though. A few approaches come to mind:

You could modify the Dockerfile to add tools you always need — just add more apt-get install or uv tool install lines for your standard toolkit. This bakes them into the image so they're always there.

You could also leverage the fact that Claude Code is running with bypassPermissions — once you're inside the container, you could just ask Claude to install what's needed and it'll run the commands without confirmation. It's not "auto" detection, but it's pretty frictionless since Claude can read your project files and figure out what's missing.

A more structured approach would be to add a script (like a post_start.sh or extend post_install.py) that reads something like a manifest file from your project and installs the listed dependencies. But nothing like that exists in the project today.

It's worth noting this project is focused specifically on the sandboxing and isolation problem, not on environment provisioning. It's a security tool from Trail of Bits, not a full dev environment manager.

I know the purpose might be obvious to people who are used to working with devcontainers but I'm not that familiar with that flow since I've always had to fight that setup so it never really stuck. I love that this tool makes it so easy to set it up and to "ssh" into the devcontainer. Thanks to the dev and contributors!

[disconnect3d]

Hi, the main goal/idea of this project is to use it within our internal security audit workflow so that we can run Claude in YOLO mode and be safe than sorry. The idea is to protect us against:

1. Claude making mistakes and e.g. running some dangerous action like rm -rf /*
2. To not get pwned with untrusted Claude projects, see https://github.com/disconnect3d/claude-pwn
3. To not get pwned with any prompt injections that may cause Claude to do 1) or worse (note that Claude's /sandbox is not that helpful for that since a user may accept to bypass the sandbox).

Regarding on how to use this, well, use it however you want! I'd say we are still playing with this more and more, improving it and we may change this further.

For example, I use this sometimes to develop the Pwndbg project which has its own devcontainer specification. In this case, I tear down its devcontainer and use the one generated by claude-code-devcontainer.

I think it would be nice to allow for some additional post configuration/setup but I am not sure if this is really required for our use case for now on. If you have any suggestions on how to improve, we are welcome to hear them and may apply them if you send a PR!

[disconnect3d]

For what is worth, we have the devcontainer-setup skill in our trailofbits/skills repository which can be used to setup a devcontainer with CC based on similar scripts as in this repo (we should probably auto-sync it) along with additional tools required for your specific project.

I guess it may be useful for what you ask for.