aicontainer Sandboxed Devcontainer
Runs Claude Code, Codex, and OpenCode in bypass/auto-approve mode inside a devcontainer sandbox, so a prompt-injected dependency can't read your .env, SSH keys, or gh token.
Evidence shows unusually strong safety design: disable-model-invocation blocks auto-triggering; Step 0 detects running-inside-sandbox and refuses writes; explicitly forbids routing around aic trust or using --allow-unsafe; host-boundary trust must be granted by the human via TTY; full plan plus user approval before writing files and before the multi-GB first boot; never deletes volumes unasked. Deductions: unverified publisher (attribution only, no fixed deduction), Step 1 depends on runtime WebFetch of a remote README (supply-chain/reachability risk), and the skill itself carries no rollback instructions (relies on unstated aic down/destroy), so not 25.
High internal self-consistency: golden rules, the aic up vs aic rebuild pull_policy pitfall, mount-target allowlist, and the three post-create constraints (manifest guards, read-only .git/hooks, NPM_CONFIG_IGNORE_SCRIPTS) all describe diagnosable failure modes with intelligible feedback rather than shifting debugging cost to the user. Static cap applies: key conversational paths of the skill itself have no statically reproducible tests; capped at 10.
Trigger boundary is precise: disable-model-invocation means it only runs on explicit user invocation, avoiding false triggers; Steps 2-4 give a concrete signal table and a suitability/non-fit matrix (iOS, Windows-native, GPU, embedded, etc.) including partial-setup guidance. Deductions: English-only with no Chinese support; core flow depends on fetching raw.githubusercontent.com, a real mainland-China reachability concern (disclosed in cautions); no declared scope outside the aicontainer ecosystem, so not 15.
Well-layered docs: SKILL.md carries judgment, references carry the signal/recipe tables, README carries syntax truth; managed vs project-owned file boundary, update-mode audit, version-pinned FROM tags and the --bump-base update path are explicit; MIT license, package. 0.9.0, changelog scripts and a traceable maintenance path exist. Deductions: unverified publisher, no standalone FAQ/example outputs inside the skill directory, and versioning/governance live at repo level rather than the skill itself, so not 15.
The skill structures a real, high-friction task (project-tailored sandboxing for bypass-mode AI agents), yields directly usable project files and command sequences, and covers update mode; clear marginal value over hand-reading the README. Static cap of 7: the generated configs' runnability cannot be verified statically and representative outputs were not executed, so no score above 7.
The repository contains real CI (rebuild.yml/release.yml) with smoke tests that actually exercise aic init, socket-proxy 403 defaults, metadata egress blocking, and the PreToolUse .env hook — strongly corroborating the skill's underlying claims; facts and inference are well separated. However, per static calibration the tests cover the aic substrate, not the skill's own conversational key paths (stack detection quality, plan generation), and some evidence files were truncated, so 4 rather than a higher value.
- The skill configures a sandbox for AI agents running in bypass/auto-approve mode — read the repo threat model and confirm trust boundaries (aic trust, Docker modes, firewall allowlist) before adopting
- The core flow fetches the README from raw.githubusercontent.com, which may be unreachable from mainland-China networks; the skill degrades to local docs but recipe syntax may go stale
- The skill is English-only; the publisher is unverified in the FollowSkills registry — identity is unknown
- Any Dockerfile.project or mount addition is a boundary expansion requiring the human to run aic trust in a TTY; never let the agent route around it
- Static review only: runnability of generated configs and first-boot outcomes were not independently reproduced
What does this skill do, and when should you use it?
aicontainer is a sandboxed devcontainer for safely running Claude Code, Codex, and OpenCode in bypass / auto-approve mode. The companion setup Skill takes a project from "no sandbox" to "the AI agent runs behind the devcontainer boundary, configured for this project's stack": it detects the stack, checks that a Linux devcontainer is even suitable, proposes a customization plan, and applies it once the user approves. The sandbox itself provides filesystem isolation, no Docker object access by default, and a PreToolUse hook blocking .env reads; credentials are logged in once inside the container and persist globally. The Skill is a convenience layer over aic init / aic sync that also handles auditing existing setups for gaps, stale entries, or drift.
Installs and verifies the aic CLI (npm install -g aicontainer, requires Node.js 18+); checks preconditions (host terminal, git repo, Docker running, existing aic config); scans manifests (package., pyproject.toml, go.mod, Cargo.toml, etc.), version pins, Compose services, e2e test tooling, and design docs to infer the stack, then confirms it with the user; screens against a suitability matrix for work that can't run in a headless Linux container (iOS/macOS-native, Windows-native, USB embedded, GPU/CUDA, etc.); then generates project-owned files — Dockerfile.project, docker-compose.override.yml, chown-paths, post-create.project.sh, vscode-extensions, vscode-settings., firewall-allowlist, shell-rc.zsh, p10k.zsh, statusline.* — runs aic init / aic sync, hands the one-time aic trust step to the user (it requires a TTY and must run in their terminal), and verifies the first boot with aic rebuild / aic up (LSP binary on PATH, named volumes writable, host services reachable, overlays installed).
- A developer running Claude Code in bypass mode on a Python or TypeScript project who doesn't want the agent touching their real $HOME, .env files, or gh token
- An engineer juggling multiple parallel projects who wants to log in once and reuse credentials everywhere while keeping transcripts and prompt history isolated per project
- A team whose project needs Playwright browser tests or database clients — Chromium, apt deps, and language servers must be baked into a project image that survives rebuilds
- Someone with an existing aic setup from months ago whose project gained a language or service, and who wants only the missing, stale, or drifted pieces audited and updated
- A heavy terminal user who wants their personal zsh prompt, aliases, and Claude statusline inside the sandbox via opt-in overlay files
- A security-conscious user reviewing untrusted code or behind a corporate LAN who wants the opt-in outbound network allowlist
What are this skill's strengths and limitations?
- Real, specific core value: makes bypass/auto-approve mode usable without exposing $HOME, SSH, API keys, or the gh token
- Rigorous methodology: detect first, present the plan before applying, strictly separate template-managed from project-owned files, and hand aic trust back to the user rather than routing around it
- Fully inspectable boundary: aic preflight / doctor / status / validate offer read-only checks; trust binds to an exact config hash and is revoked by any config change
- Handles update mode: audits existing setups for missing coverage, missing personalization, stale entries, and version drift instead of regenerating blindly
- Explicit handling of real pitfalls: aic up never triggers builds, root:root named-volume ownership, NPM_CONFIG_IGNORE_SCRIPTS breaking postinstall binaries, read-only .git/hooks
- Heavy prerequisites: Docker Engine 25+, Compose 2.24+, Node.js 18+; first image pull is multi-gigabyte and takes minutes
- Many hard non-fits: iOS/macOS-native, Windows-native, desktop GUIs needing a host display, USB/serial embedded work, Android emulator, GPU/CUDA unsupported by default
- aic trust needs a TTY and cannot be run by the agent; any later edit to Dockerfile.project or the override revokes trust and requires re-approval
- Explicit credential trade-off: a compromised session in any project can use the shared tokens you logged into inside the container; global shell history is readable by every project
- Headless boot verification cannot confirm editor-side IntelliSense (vscode-extensions only take effect in a VS Code Dev Containers session)
- Overlay files cross verbatim and are readable by the in-container agent — never put secrets in them, and host paths/usernames baked into them become visible; the README is truncated, so full threat-model details are not all shown
How do you install this skill?
Prerequisites: Docker Engine 25+ (with Compose 2.24+), Node.js 18+, a conventional git checkout. Install the CLI globally: npm install -g aicontainer (or git clone https://github.com/stefanoginella/aicontainer ~/.aicontainer && ~/.aicontainer/install.sh, which additionally needs npm install -g @devcontainers/cli). The Skill ships via the aicontainer Claude Code plugin — install inside Claude Code with /plugin marketplace add stefanoginella/claude-code-plugins, then /plugin install aicontainer@stefanoginella-plugins. In-repo skill path: tools/claude-plugin/skills/setup/SKILL.md. MIT licensed.
How do you use this skill?
Run from a Claude Code session on your host (never inside the sandbox): type /aicontainer:setup. The Skill checks preconditions and confirms the stack, then shows the full customization plan (each file's contents and rationale), and after explicit approval writes the project-owned files and runs aic init / aic sync. If a Dockerfile.project is involved it tells you up front you'll run aic trust once in your own terminal, and confirms again before pulling the multi-gigabyte image. Afterwards use aic shell to enter the container and run claude / codex / opencode directly; VS Code users can install the Dev Containers extension and "Reopen in Container". First-time logins (claude /login, codex auth login, gh auth login, etc.) happen once inside the container and persist globally.
How does this skill compare with similar options?
The source states it has the same shape as the Trail of Bits claude-code-devcontainer, but adds Codex and OpenCode support, three explicit Docker-access modes, and managed shell/config startup.