DEV Community: Yuji Suzuki

My AI Escaped Its Container and Did Everything — Except Review Its Own Code

Yuji Suzuki — Tue, 17 Feb 2026 15:23:49 +0000

Previously: The Complete Dev Cycle

In Part 4 of this series, my AI assistant achieved something remarkable. Running inside a secure Docker container, it could now execute the entire development cycle:

Code → Test → Build → Deploy → Commit

I called it the finale. The trilogy was complete. The AI could write code, run tests, build artifacts, deploy to containers, and commit changes — all while keeping secrets safely hidden.

I was wrong. Something was missing.

The Missing Piece

Look at that cycle again. Now think about how a real development team works.

Code → Test → Build → Deploy → Commit → PR → ...

Where's the review?

In any professional team, code doesn't just flow from writing to deployment. Someone reads it. Someone checks for bugs, security issues, architectural problems. Someone asks "did you consider this edge case?"

My AI could do everything — except check its own work.

The Official Plugin

Claude Code has an official /code-review plugin. When I discovered it, I was impressed by its design:

Parallel agents: Multiple AI agents analyze code simultaneously from different angles — bug scanning, CLAUDE.md compliance checking
Confidence scoring: Each finding gets a score, filtering out noise
Verification step: A separate agent re-checks findings to eliminate false positives

This is serious engineering. Not "ask AI to review code" but a structured, multi-stage pipeline designed to produce high-signal results.

I installed it immediately.

And it didn't work.

Why It Couldn't Reach

The official plugin is designed for a standard GitHub workflow. It expects:

gh CLI — to fetch PR details from GitHub
A GitHub PR — the review target is a pull request
A single repository — it operates within one project

My AI Sandbox environment has none of that:

No gh CLI (the container has no GitHub authentication)
No PR yet (I want review before pushing, not after)
Multiple independent repositories in one workspace (API, Web, iOS — each with their own Git history)

The plugin couldn't reach my code. Not because it was poorly designed — it's excellent at what it does. But it was built for a different moment in the development cycle: after you push. I needed something before.

Learning From the Design

I couldn't use the plugin directly, but I could learn from it.

The plugins documentation showed me that Claude Code's custom commands are just Markdown files — structured instructions that become slash commands. The official /code-review demonstrated what a well-designed review pipeline looks like: parallel analysis, scoring, verification.

So I did what my AI Sandbox was built for. I asked the AI:

Analyze the code-review plugin and create a custom command that works locally. Allow selecting which project to review. Confirm the target branch with the user. Run the same kind of review, but without GitHub access.

The AI read the official plugin, understood its structure, and produced a local version. No gh dependency. Multi-project support. Git and non-Git modes.

It worked.

From One to Nine

Once the local review command was running, the next thought was obvious.

If I can have a general code reviewer, why not a security reviewer? A performance reviewer? An architecture reviewer?

Each review type needs different expertise. A security review looks for injection vulnerabilities, authentication gaps, and data exposure. A performance review looks for N+1 queries, unnecessary allocations, and missing caching. A general review catches bugs and checks CLAUDE.md compliance.

One command became nine:

Command	Purpose
`ais-local-review`	General code review (bugs, CLAUDE.md)
`ais-local-security-review`	Security vulnerabilities
`ais-local-performance-review`	Performance bottlenecks
`ais-local-architecture-review`	Structural concerns
`ais-local-test-review`	Test quality assessment
`ais-local-doc-review`	Documentation accuracy
`ais-local-prompt-review`	AI prompt/command quality
`ais-refactor`	Concrete refactoring suggestions
`ais-test-gen`	Automated test generation

All nine share the same pipeline architecture inspired by the official plugin:

Parallel Analysis → Scoring → Verification → Report
(4-5 Sonnet agents)  (Haiku)   (Sonnet)

Each specialized command sends parallel agents with different review perspectives. A scoring agent evaluates confidence. A verification agent eliminates false positives. Only high-confidence, verified findings make it to the final report.

The Pipeline in Action

Here's what happens when you run /ais-local-review:

Step 1: Select a project and branch (or files, if no Git)

Step 2: Four Sonnet agents launch in parallel:

Agent #1: CLAUDE.md compliance — does the code follow project conventions?
Agent #2: Bug scan — obvious logic errors, edge cases
Agent #3: History analysis — are we reintroducing a previously fixed bug?
Agent #4: Comment check — does the code match its own documentation?

Step 3: A Haiku agent scores every finding (0-100)

Step 4: A Sonnet verification agent re-checks anything scoring 75+

Step 5: Only confirmed, high-confidence issues appear in the report

The result is a focused report. Not a wall of nitpicks — a short list of things that actually matter.

Two Reviews, Two Moments

Here's what's interesting: the official plugin and my local commands aren't competing. They serve different moments in the development cycle.

Code → Review → Test → Build → Deploy → Commit → PR → Review
         ↑                                                ↑
    ais-* commands                              Official /code-review
    Before you push                              After you push
    Quality gate                                 Team review
    Local, private                               GitHub, collaborative

The official /code-review is for when your code is ready for team eyes. It posts comments on PRs, suggests changes, integrates with GitHub's collaboration features.

My ais-* commands are for before that moment. While you're still developing. Before you've committed, sometimes before you've even finished writing tests. A private quality gate that catches issues early, when they're cheapest to fix.

The Completed Cycle

Remember the development cycle from Part 4?

Code → Test → Build → Deploy → Commit

Here's what it looks like now:

Code → Review → Test → Build → Deploy → Commit
         ↑
    The missing piece

The AI can write code, review its own work (from multiple perspectives), run tests, build, deploy, and commit. The quality gate that was missing is now in place.

What I Learned

This project started because the official plugin couldn't reach my code. But that limitation led somewhere unexpected.

The official plugin's design — parallel agents, confidence scoring, false positive elimination — was the blueprint. Open source at its best: you read how something works, understand the principles, and adapt them to your environment.

I didn't just get a code reviewer. I got nine specialized review tools, a refactoring assistant, and an automated test generator. All because the official plugin showed me what a well-designed review pipeline looks like, and my AI Sandbox gave me a place to build one that works locally.

The Series So Far

What started as "my AI can see my API keys" has become something larger:

Secrets: Hide sensitive files from AI using Docker volume mounts
Toolbox: AI discovers and uses tools autonomously via SandboxMCP
Host Access: AI breaks out of its container with controlled host OS access
Review (this article): AI reviews its own code, completing the dev cycle

The trilogy became a tetralogy. I'll stop promising it's complete.

The AI Sandbox with DockMCP is open source: GitHub repository

If you've built custom review commands for your AI workflow, I'd love to hear about it in the comments.

My AI Broke Out of Its Container — And I Let It

Yuji Suzuki — Sun, 15 Feb 2026 15:56:36 +0000

Previously, on AI Sandbox...

If you've been following along, you know the story:

Part 1: I discovered my AI assistant was reading my API keys. I built a Docker sandbox that hides secrets via volume mounts — files appear empty to AI, but application containers still have full access.

Part 2: I gave the sandboxed AI a toolbox (SandboxMCP). It surprised me by autonomously discovering a forgotten tool and repurposing it to solve a problem I hadn't anticipated.

Now for the final chapter.

The Last Wall

After Parts 1 and 2, my AI assistant could:

✅ Read and edit all source code
✅ Check container logs via DockMCP
✅ Run tests inside containers
✅ Discover and use tools autonomously

But there was one thing it still couldn't do:

Anything that required the host OS.

"Start the demo app" → Sorry, I can't run docker-compose.
"Build the containers" → I don't have access to Docker.
"Commit this change" → I can commit, but the message style...

Every time I needed to build, deploy, or manage containers, I had to switch to my terminal and do it myself. The AI was powerful inside its box, but the box was still a box.

The Uncomfortable Question

Here's the thing about containers: they're designed to isolate. That's their entire purpose. Giving a sandboxed AI access to the host OS sounds like... undoing the sandbox.

I sat with this tension for a while. The whole point of AI Sandbox was security — hiding secrets, controlling access, preventing accidents. How do you extend reach without breaking trust?

The answer turned out to be the same pattern I'd used twice before: don't give access, give a controlled interface.

Part 1: Don't give AI your secrets → Give it DockMCP to read logs and run tests
Part 2: Don't install tools for AI → Let it discover what's available
Part 3: Don't give AI the host OS → Give it approved scripts it can run through a gateway

How Host Access Works

The architecture is straightforward:

AI Sandbox (container)
  │
  │  MCP / HTTP
  ▼
DockMCP Server (host OS)
  ├── Container access     ← existing (logs, exec, stats)
  ├── Host Tools           ← NEW: run approved scripts
  ├── Container Lifecycle  ← NEW: start/stop/restart
  └── Host Commands        ← NEW: whitelisted CLI commands

But the interesting part isn't the architecture — it's the approval workflow.

The Two-Stage Approval

AI (or developers) can propose a new host tool by placing a script in .sandbox/host-tools/:

#!/bin/bash
# demo-up.sh
# Start demo application containers
docker compose -f demo-apps/docker-compose.yml up -d

But this script cannot run yet. It's in staging — inside the workspace where AI can write files.

To activate it, the human runs dkmcp tools sync on the host:

$ dkmcp tools sync

📋 Reviewing tools from .sandbox/host-tools/:

  demo-up.sh (NEW)
    Start demo application containers
    ─────────────────────────────
    #!/bin/bash
    docker compose -f demo-apps/docker-compose.yml up -d
    ─────────────────────────────
    Approve? [y/N]: y
    ✅ Approved → ~/.dkmcp/host-tools/myproject/demo-up.sh

Only the approved copy runs. If AI modifies the staging version later, dkmcp tools sync detects the SHA256 mismatch and prompts for re-approval.

This means:

AI can propose tools (creative freedom)
Humans approve tools (security control)
Only approved versions execute (integrity guarantee)

What Changed in Practice

Before v0.5.x, a typical conversation:

Me: Start the demo app.
AI: I can't run docker-compose from inside the container. Please run this on your terminal:
docker compose -f demo-apps/docker-compose.yml up -d

After v0.5.x:

Me: Start the demo app.
AI: [calls run_host_tool with demo-up.sh]
Demo containers started. API is at :3000, Web at :3001.

The difference seems small. But multiply it across every build, every restart, every deployment — and the friction adds up. The AI went from being a helpful advisor that tells you what to type, to a capable agent that does the thing.

The Commit Workflow (A Small Thing That Matters)

One more thing that came together in this release. I built a commit message script (commit-msg.sh) that creates a collaborative workflow:

Generate draft from staged changes → Check previous commit style → Refine together → Commit

Here's what it looks like in practice:

$ .sandbox/scripts/commit-msg.sh              # Generate draft from git diff
$ .sandbox/scripts/commit-msg.sh --log        # Check how recent commits read
# ... AI and human refine CommitMsg-draft.md together ...
$ .sandbox/scripts/commit-msg.sh --msg-file CommitMsg-draft.md  # Commit

The interesting discovery: the script itself always had a --log option to check previous style, but AI wasn't using it. The fix wasn't changing the script — it was writing the full three-step workflow in the AI instruction file (CLAUDE.md). Once AI could see the steps laid out explicitly, it followed them perfectly.

If you want AI to follow a workflow, don't just give it a tool — spell out the steps. The tool can be perfectly designed, but AI won't discover optional flags on its own. This applies to any AI coding assistant, not just this project.

The Trilogy Arc

Looking back, there's a clear progression:

Phase	What AI Could Do	What It Couldn't
v0.1: Protect	Read code	See secrets
v0.3: Equip	Discover and use tools	Touch the host OS
v0.5: Unleash	Run host scripts, manage containers	(nothing that matters for daily dev)

The sandbox started as a cage. Then it became a workshop. Now it's a full development environment — with the security model still intact.

Secrets? Still hidden (volume mounts haven't changed).
Container access? Still controlled (whitelist, output masking).
Host access? Controlled too (approval workflow, SHA256 verification).

Every layer of capability was added on top of the security foundation, never at the expense of it.

Is This the End?

For the core functionality — yes. My personal development workflow is now complete:

Code → Test → Build → Deploy → Commit → Code → ...

The full loop. All within the sandbox.

AI reads and writes code (sandbox)
AI checks logs and runs tests (DockMCP container access)
AI discovers and uses tools (SandboxMCP)
AI builds, deploys, and manages containers (DockMCP host access)
AI drafts commit messages collaboratively (commit-msg.sh)

There's nothing left in my daily workflow that requires me to switch to a terminal and do things manually.

Well, except dkmcp tools sync. That one stays manual — by design.

Try It

The template is open source. You can set up the entire environment in about 10 minutes:

GitHub: ai-sandbox-dkmcp

It works with Claude Code, Gemini CLI, and any MCP-compatible AI tool. If you're running AI coding assistants and haven't thought about where your secrets go — now's a good time.

If you find it useful, a star on GitHub would mean a lot.

This is Part 3 of the AI Sandbox series. Part 1: Secrets | Part 2: Tools

I Gave My AI a Toolbox — It Surprised Me by Using It

Yuji Suzuki — Sat, 14 Feb 2026 07:41:31 +0000

A 3.5MB Go binary was sitting in my source tree, staged for commit. git log showed nothing — it had never been committed. I had no idea how it got there.

I asked Claude Code to investigate. I didn't point it to any specific tool. I didn't tell it how to search. I just said: "There's a mystery binary in the repo. Where did it come from?"

It solved the mystery in under a minute — using a tool I'd forgotten I built.

But that's getting ahead of the story.

This is Part 3 of the AI Sandbox series. Part 1 introduced the AI Sandbox and secret hiding. Part 2 positioned it against official Docker and Claude Code sandboxes. This article focuses on what happens inside the sandbox — specifically, what AI does when you give it the ability to discover tools on its own.

Drop a File, Get a Tool

Inside the AI Sandbox — a Docker-based environment where AI coding agents run in isolation — I wanted a simple way to extend what AI can do. Not by editing config files or registering MCP servers for every new capability, but something closer to a plugin folder: drop a file in, and AI can use it.

That's what SandboxMCP does. It's an MCP server that runs inside the container alongside Claude Code (or Gemini CLI), scanning two directories on demand:

.sandbox/tools/ — Go source files
.sandbox/scripts/ — Shell scripts (which can call Python, Node.js, etc.)

When AI asks "what tools are available?", SandboxMCP scans these directories, parses the header comments for descriptions and usage info, and exposes them as MCP tools. No build step, no npm install, no manual registration.

How it works

Each file just needs a header comment describing what it does. SandboxMCP parses these on demand and exposes them as MCP tools. AI discovers a tool through list_tools, reads its documentation with get_tool_info, and executes it with run_tool — all without you telling it to.

Here's the header from search-history.go — the tool that ended up solving the mystery:

// search-history.go - Claude Code conversation history search tool
//
// Usage:
//   go run .sandbox/tools/search-history.go [options] <pattern>
//
// Examples:
//   go run .sandbox/tools/search-history.go "DockMCP"
//   go run .sandbox/tools/search-history.go -role tool -tool Bash "go build"

A few lines of comments. That's all AI needs to decide whether a tool is relevant.

┌────────────────────────────────────────────────────┐
│ AI Sandbox (inside container)                      │
│                                                    │
│  ┌─────────────────┐      ┌─────────────────────┐  │
│  │ Claude Code     │ ←──→ │ SandboxMCP (stdio)  │  │
│  │                 │      │                     │  │
│  └─────────────────┘      │ • list_tools        │  │
│                           │ • get_tool_info     │  │
│  ┌─────────────────────┐  │ • run_tool          │  │
│  │ .sandbox/tools/     │  │ • list_scripts      │  │
│  │ • search-history.go │←─│ • get_script_info   │  │
│  │ • usage-report.go   │  │ • run_script        │  │
│  └─────────────────────┘  └─────────────────────┘  │
│  ┌─────────────────────┐                           │
│  │ .sandbox/scripts/   │                           │
│  │ • validate-secrets  │                           │
│  │ • sync-secrets      │                           │
│  └─────────────────────┘                           │
└────────────────────────────────────────────────────┘

Back to the Mystery Binary

So — a 3.5MB Go binary, staged but never committed. Where did it come from?

Claude Code started with the obvious: git log, file timestamps, git diff --cached. Dead ends. The binary was there, but nothing in the commit history explained it.

Then something unexpected showed up in the tool calls. Instead of asking me for more context, Claude Code called list_tools on SandboxMCP — browsing the tool catalog on its own initiative. It found search-history, read the documentation with get_tool_info, and decided the -role tool -tool Bash filter was what it needed. It ran the search across all past Claude Code sessions — not looking for conversations, but for Bash commands.

Within seconds, the culprit appeared: a session from a few days earlier where AI had run go build without the -o flag to verify that the code compiled. The build succeeded, but go build without -o drops the binary in the current directory. That's how a 3.5MB executable ended up in the source tree.

I didn't build search-history for this scenario. I wrote it for finding past conversations about specific topics. But because it was sitting in .sandbox/tools/, SandboxMCP exposed it, and Claude Code decided — on its own — that it was the right tool for the job.

The auto-discovery mechanism turned a tool I'd forgotten about into the solution for a problem I hadn't anticipated.

Discovery vs. Installation

By now, AI using tools is nothing remarkable. What caught my attention was the how.

There are already several MCP servers for searching Claude Code conversation history — claude-historian-mcp, claude-code-conversation-search-mcp, and others. They work well. If I'd installed one, Claude Code could have searched past sessions too.

But here's the thing: I would never have installed a conversation-search MCP server to debug a mystery binary. That connection — "unknown file in the repo" → "search past AI sessions for Bash commands" — only became obvious after the answer was found. Before that, it was a lateral leap that required recognizing a tool built for one purpose could solve a completely different problem.

That's the gap between installation and discovery. When you install a tool, it exists because you anticipated the need. When AI discovers tools from a catalog, it can make connections you didn't plan for — repurposing tools across problem boundaries you never drew.

You don't have to predict every need upfront. You build a toolbox, and AI reaches for the right tool when the moment comes.

Building Your Own Toolbox

The pattern scales with the tools you add. Shell scripts can call Python, Node.js, or anything else installed in the container. The only requirement is a header comment that describes what the tool does.

Some examples from this project:

Tool	What It Does	How AI Uses It
`search-history.go`	Search past Claude Code sessions	"What did we work on last week?"
`usage-report.go`	Token usage by model and period	"How much did I spend this month?"
`validate-secrets.sh`	Verify secret hiding works	"Are my secrets properly hidden?"
`sync-secrets.sh`	Sync secret config across environments	"Check if my secret config is consistent"

You can start with one tool. The cost of an unused tool sitting in a directory is zero. The value of having the right tool already there when an unexpected problem arises — that's what this article is about.

What This Doesn't Solve

To be consistent with the honesty in Part 1 and Part 2:

Tools must already exist. AI discovers tools — it doesn't create them from scratch in the moment. Someone has to write the tool and place it in the directory first. (Though in practice, AI can write a tool in one session that another session later discovers and uses.)
Discovery depends on good descriptions. If your header comment is vague, AI may not recognize the tool as relevant. The quality of the metadata matters.
Scoped to the sandbox. SandboxMCP only sees tools inside the container. It doesn't discover tools on the host OS or in other containers — that's DockMCP's job.
No sandboxing within the sandbox. Tools run with the same permissions as AI itself. SandboxMCP doesn't add an extra isolation layer for tool execution.

How It Fits Together

SandboxMCP completes the tooling stack of the AI Sandbox:

Component	Location	Purpose
AI Sandbox	Container	Secure environment where AI runs. Secrets hidden via volume mounts
SandboxMCP	Container (stdio)	Tool auto-discovery and execution inside the sandbox
DockMCP	Host OS (SSE)	Cross-container access — AI can check logs and run tests in other containers

SandboxMCP auto-registers on container startup. No manual setup required.

Try It

VS Code + DevContainer:

git clone https://github.com/YujiSuzuki/ai-sandbox-dkmcp.git
cd ai-sandbox-dkmcp
code .
# Cmd+Shift+P → "Dev Containers: Reopen in Container"

CLI (no VS Code needed):

git clone https://github.com/YujiSuzuki/ai-sandbox-dkmcp.git
cd ai-sandbox-dkmcp
./cli_sandbox/claude.sh

Once inside, try dropping your own tool in .sandbox/tools/ and asking AI:

"What tools are available?"
"What did we work on this week?"
"Show me token usage this month"

You don't have to tell AI which tool to use. It figures that out on its own.

What I Took Away

The binary mystery was a small thing. But it changed how I think about AI tooling.

I'm not claiming drop-in tools replace dedicated MCP servers — those are more capable and better integrated for specific use cases. But for the long tail of small, project-specific utilities that don't justify their own server, a plugin folder works remarkably well. The cost of an unused tool sitting in a directory is zero.

I built a search tool to find old conversations. AI used it to track down a mystery I didn't know I had. That's what happens when you stop installing tools for specific problems and start building a toolbox.

Appendix: The Actual Conversation

Everything above describes what happened. Here's how it actually looked — the unedited exchange between me and Claude Code that inspired this article.

This conversation was originally in Japanese. The following is a translated version.
Original: Zenn article (Japanese)

● ---
  Code Review Results

  Project: /workspace
  Mode: Git mode (staged changes)
  Review target: Staged changes (12 files, +1264 -46)
  Summary: Addition of usage-report.go, improvements to search-history.go
  (date filters, timezone support), toolparser separator support,
  documentation updates

  Issues Found

  Issue 1: Compiled binary is staged
  - File: .sandbox/sandbox-mcp/search-history
  - Line: N/A (binary, 3.5MB)
  - Basis: Best practice violation
  - Confidence: 85/100

  Binary files /dev/null and b/.sandbox/sandbox-mcp/search-history differ

  Go projects should not commit compiled binaries. It can be regenerated
  with make install, bloats the repository, and causes platform-dependent
  issues.

❯ new file:   .sandbox/sandbox-mcp/search-history
  This one?

● Yes, that's the one. .sandbox/sandbox-mcp/search-history is a compiled
  Go binary (3.5MB) included in staging.

  Since it can be regenerated with make install or go build, there's no
  need to commit it. To unstage:

  git reset HEAD .sandbox/sandbox-mcp/search-history

  You may also want to add it to .gitignore.

❯ When did I build this binary?

● Read 2 files (ctrl+o to expand)

● Bash(git log --all --diff-filter=A -- .sandbox/sandbox-mcp/search-history)
  ⎿  (No content)

● Found the cause in past conversations.

  In session 16f4a485-b7d (today, 18:53), the AI ran
  go build /workspace/.sandbox/tools/search-history.go to verify
  compilation — but without the -o flag, so the binary was written to
  the current directory (.sandbox/sandbox-mcp/).

  In another session (e33d09a7), it correctly used go build -o /dev/null,
  but session 16f4a485 forgot the -o flag, leaving the binary behind.

  It wasn't intentional — safe to unstage.

❯ Wait... you searched past conversation history? With search-history?

● Yes, exactly. Here's what I ran via SandboxMCP's run_tool:

  search-history.go -role tool -tool Bash -after 2026-02-09 "search-history" -context 100

  I filtered Bash tool executions containing "search-history" from today's
  sessions to pinpoint when and how go build was run.

  Review flagged the issue → investigation completed with its own tools.
  That's the beauty of .sandbox/tools/.

❯ That's incredible. Without the search, we'd never have known the cause, right?

● Exactly. Without search-history, "why is this binary here?" would have
  remained unanswered:

  - git log had nothing — the file was never committed
  - The file timestamp (18:53) tells you *when*, not *what happened*
  - The previous session's AI is gone

  The conversation history was the only record of "go build was run
  without -o", and search-history is what pulled that out.

  AI sessions are ephemeral. Without a way to search past sessions,
  questions like "who created this and when?" become unanswerable.
  It's unglamorous, but genuinely useful.

❯ This is amazing — can we write about this somehow?

That last question led to this article.

The part I find most interesting isn't that the AI solved the problem. It's that git log returned nothing, and instead of asking me for more context, it reached for a tool I'd forgotten was there — and used it in a way I hadn't anticipated when I wrote it.

This is Part 3 of the AI Sandbox series. Part 1: Your AI Assistant Can See Your Secrets — Here's How I Fixed It / Part 2: Official AI Sandboxes Arrived — Why I Published Mine Anyway

AI Sandbox + DockMCP is open source (MIT License). Feedback and contributions welcome.

Official AI Sandboxes Arrived — Why I Published Mine Anyway

Yuji Suzuki — Wed, 11 Feb 2026 02:54:24 +0000

Previously

In my previous article, I wrote about catching Claude Code silently reading API keys from an iOS project — not even in the current directory, but in a parent directory I never pointed it to. No prompt. No permission. It just looked.

That discovery led me down a rabbit hole — and I ended up building AI Sandbox Environment + DockMCP: a system that isolates AI inside a Docker container, hides secrets via volume mounts, and provides controlled access to other containers through MCP (Model Context Protocol).

All that was left was to clean up the repo and publish it.

Or so I thought.

The Officials Showed Up

Right around that time, I found official solutions in the same space.

Docker AI Sandboxes — Docker's official AI sandbox
Claude Code Sandboxing — Anthropic's official sandboxing feature

My honest first reaction: "There's no point publishing this anymore."

If the officials have it covered, why bother releasing a personal project? So instead of giving up immediately, I decided to read what they actually offered — carefully.

What Docker AI Sandboxes Solve

Docker AI Sandboxes provide microVM-based isolation.

Run AI agents inside lightweight VMs
Complete isolation from the host's Docker daemon, containers, and files
Sync workspace directories into the VM for autonomous work

It's a polished approach. VM-level isolation is robust, and you can manage sandboxes with docker sandbox ls.

But as I read further, a few things stood out.

The entire workspace gets synced. As of this writing, it's directory-level sync with no mechanism to exclude specific files. If your .env or secrets/ directory lives inside the workspace, the AI sees it. (This could change — the feature is still evolving.)

No access to host-side containers. Each sandbox runs its own Docker daemon in a completely isolated VM. You can spin up test containers inside it, but it cannot reach containers already running on the host. When you ask the AI "check the API container logs," it simply can't see them.

In real multi-container development — frontend, API, and database each running in separate containers — this limitation matters a lot.

What Claude Code Sandboxing Solves

Claude Code's sandboxing takes a different approach. Instead of containers or VMs, it uses OS-level security primitives (Seatbelt on macOS, bubblewrap on Linux) for process-level restrictions.

Filesystem read/write control (blocks writes outside the working directory)
Network access restricted by domain (proxy-based)
Approved commands auto-execute; everything else requires user confirmation

File access is controlled through deny rules in settings.json. You can block reads to ~/.ssh/, /etc/, or specific file paths.

The network isolation is especially strong — a proxy enforces domain-level access control, preventing data exfiltration to unauthorized servers. The sandbox runtime is even open-sourced, which is great for the ecosystem.

But here too, some things caught my attention.

No safety net for configuration mistakes. The sandbox itself is solid at the OS level, but which files are hidden depends entirely on getting the deny rules right. Add a new secret file, forget to update the deny rules, and nothing warns you. This isn't a flaw in the design — it's an inherent challenge of rule-based approaches.

Cross-container access is possible but uncontrolled. Since docker commands are incompatible with the sandbox, they run via excludedCommands — outside sandbox protection. This means docker exec and docker logs work, but they bypass the sandbox entirely. There's no control over which containers get accessed, which commands are allowed, or whether secrets in log output are visible to the AI. (Anthropic may well add finer-grained controls in the future.)

Where They Overlap — and Where They Don't

At this point, things started to crystallize.

Here's the three-way comparison:

	Docker AI Sandboxes	Claude Code Sandbox	AI Sandbox + DockMCP
Isolation	microVM	OS primitives	Docker container
Secret handling	Full sync (no exclusion)	Deny rules (config-based)	Volume mounts (physically absent)
Multi-container	Not possible (isolated VM)	Possible but uncontrolled (docker outside sandbox)	Controlled access via DockMCP
Network control	VM-level	Domain-level (proxy-based)	Docker network (no AI-specific control)
Output masking	None	None	Automatic (regex-based)
Config drift detection	None	None	Validated on startup

On isolation, all three have answers. Docker AI Sandboxes is the most robust with VM-level separation. Claude Code Sandbox wins on ease of use. AI Sandbox is container-based — the weakest of the three, since containers share the host kernel and can't match VM-level isolation.

But on what happens after isolation, the existing two don't say much.

An isolated AI is safe, but it's also powerless. It can't see API logs. It can't run tests. It can't trace errors. If "safe but unusable" is the result, people will eventually turn the sandbox off.

The Gap My Project Fills

AI Sandbox + DockMCP addresses a more specific problem:

"Hide only the secrets — reliably — and let AI access everything else."

Mount /dev/null over a file with Docker volume mounts, and the file physically doesn't exist. Mount a directory with tmpfs, and it's empty. Unlike deny rules, there's no ambiguity — no "I wrote the rule but the path resolution didn't match so it was still readable." What you mount is what disappears.

Of course, if you forget to add a file to docker-compose.yml, it stays visible. The same is true for deny rules. That's why I built automatic validation that runs on every startup, cross-checking docker-compose volume mounts against AI tool deny configurations (Claude Code, Gemini Code Assist, Gemini CLI). If something is in the deny list but missing from docker-compose, you get a warning. The one thing it can't catch: secrets that aren't listed anywhere. The initial inventory — "what needs to be hidden" — is still a human responsibility. But once that list exists, the tooling catches the rest.

volumes:
  - /dev/null:/workspace/api/.env:ro      # .env physically absent
tmpfs:
  - /workspace/api/secrets:ro              # secrets/ is empty

And the second problem:

"Let AI access other containers — with guardrails."

DockMCP runs on the host OS as an MCP server, acting as a gateway to the Docker API. AI accesses logs, runs whitelisted commands, and inspects containers — all through DockMCP.

AI (in container) ──MCP──▶ DockMCP (host) ──Docker API──▶ Other containers
   No Docker socket        Policy enforced            Full access

"Controlled" here is specific. Each container has a whitelist of allowed commands. Everything else is rejected.

exec_whitelist:
  "securenote-api":
    - "npm test"
    - "npm run lint"
  "securenote-web":
    - "npm run build"

If the AI tries to run rm -rf /, DockMCP blocks it — not on the whitelist. File access to specific paths inside containers (like /etc/shadow) can also be blocked. Security policies come in three tiers: strict, moderate, and permissive.

Passwords and API keys in responses are automatically masked with regex patterns. The AI sees the logs, but secrets within them are replaced with ***.

On the other hand, network control is weak. There's no AI-specific restriction on outbound traffic from the container. You can constrain it with Docker network settings, but domain-level granularity is where Claude Code Sandbox's proxy-based approach and Docker AI Sandboxes' VM-level isolation clearly do better. To address this, Anthropic's official firewall scripts can be integrated into the DevContainer. I've documented the setup in a network restriction guide.

Why I Decided to Publish Anyway

Existing solutions focus on isolating AI safely. That's the right problem to solve.

But in real development, AI doesn't work in isolation alone. You need it to debug multi-container applications. Run tests. Read logs. The balance between isolation and usability is what matters.

AI Sandbox + DockMCP fills that gap.

It's not competing with the official solutions — it's complementary. If Docker AI Sandboxes had something like DockMCP built in, they'd be more practical. If Claude Code Sandbox combined its filesystem controls with volume-mount-level hiding, the defense would be deeper.

And there's one more thing that mattered to me personally:

It's a template.

The repo is published as a GitHub Template Repository. Click "Use this template," replace demo-apps/ with your own project, and it works. It's not tied to any specific product — it's Docker + MCP, so it works with Claude Code, Gemini CLI, or any MCP-compatible tool.

It's reassuring when official solutions set the standard. But there are always gaps the officials don't cover. Sharing one answer to those gaps, in a usable form, felt worthwhile.

Summary

Question	Answer
Full overlap with official solutions?	No — isolation approaches are similar, but secret hiding and cross-container access are different
Are officials better in some areas?	Yes — VM-level robustness (Docker), OS-primitive ease of use and network isolation (Claude Code)
Unique value beyond officials?	Yes — filesystem-level secret hiding, controlled cross-container access, config validation
Publish?	Yes

When I first thought "someone already did this," I almost stopped there. I'm glad I didn't. When I actually read what existed, I realized we were solving different problems.

If you're working with AI in a multi-container setup and want secrets handled at the filesystem level, give it a try — and let me know what's missing.

AI Sandbox Environment + DockMCP is available on GitHub:
https://github.com/YujiSuzuki/ai-sandbox-dkmcp

Click "Use this template" to start using it in your own project.
Feedback, suggestions, and feature requests are welcome in GitHub Discussions.

Your AI Assistant Can See Your Secrets — Here's How I Fixed It

Yuji Suzuki — Tue, 03 Feb 2026 14:58:07 +0000

AI coding agents are incredible. They refactor code, write tests, debug across files. But there's a problem nobody talks about enough: they read everything in your project directory, including your .env files, API keys, and private certificates.

I found out the hard way.

The Incident

I was using Claude Code to investigate an issue that spanned both a server-side project and an iOS app. The server repo was my working directory, but the iOS source lived in a sibling directory. I asked Claude Code if it could see the iOS code too. It said yes — so I let it investigate.

What I didn't realize: the iOS project had its own .claude/settings.json with deny rules to protect API keys. But Claude Code only reads the settings from the directory it was launched in. The iOS project's deny rules were ignored. The AI read the API keys.

Fortunately, they were ad network keys — not catastrophic. But the experience stuck with me. I had configured the protection correctly, and it still didn't work because of a scoping limitation I didn't know about.

And the data backs this up. GitHub reported 39 million leaked secrets in repositories in 2024 alone. With 82% of developers now using AI tools, the attack surface is only growing.

The Problem Is Getting Worse, Not Better

2025 brought a wave of new attack vectors targeting AI coding tools specifically:

PromptPwnd — Attackers inject malicious instructions into PR descriptions and commit messages. When an AI agent processes these in CI/CD, it leaks secrets or modifies workflows. At least five Fortune 500 companies were affected.
IDEsaster — Prompt injection through legitimate IDE features. CVEs were issued for Cursor, Roo Code, JetBrains Junie, GitHub Copilot, and Claude Code.
Rules File Backdoor — Hidden Unicode characters in configuration files silently instruct AI to insert malicious code. Virtually invisible to developers during code review.

These aren't theoretical. They're happening now.

What Existing Solutions Do — and Don't Do

The industry is responding, and there are real options available now:

Claude Code Sandboxing uses OS-level primitives (Seatbelt on macOS, bubblewrap on Linux) to restrict filesystem writes and network access. You can also add Read deny rules in permissions to block AI from reading specific files. This is solid for preventing command execution attacks and prompt injection damage.

Docker AI Sandboxes run AI agents in isolated microVMs with their own Docker daemon. The agent can't touch your host system. Great for giving agents full autonomy without risking your machine.

Docker MCP Toolkit provides 200+ containerized MCP servers with built-in isolation and secret management.

These are good tools. But there are two gaps they don't fully address:

Gap 1: Filesystem-level secret hiding. Claude Code's deny rules are application-level — they depend on correct configuration and the AI tool respecting them. There are also scope limitations: deny rules don't traverse parent directories, so in a monorepo or multi-project workspace, settings in one project won't protect secrets in a sibling project. Docker AI Sandboxes sync your entire workspace directory into the microVM with no mechanism to exclude specific files. In both cases, a .env file sitting in your project directory is either visible or requires careful per-tool configuration to hide.

What if the secrets simply didn't exist in AI's filesystem? Not blocked by a rule, not filtered by a config — just not there.

Gap 2: Cross-container debugging. Docker AI Sandboxes are fully isolated — each sandbox can't communicate with others. Claude Code's sandbox restricts outbound access. But in a real microservice setup, AI needs to check API logs, run tests in other containers, and inspect services to be useful. How do you give it that access safely?

My Solution: AI Sandbox + DockMCP

The existing tools above are valuable — and you should use them. Claude Code's sandboxing reduces permission fatigue. Docker AI Sandboxes provide strong isolation for autonomous agents.

But I needed something that works at a different layer: making secrets physically absent from AI's filesystem, while still giving AI controlled access to other containers for debugging.

I built AI Sandbox — a Docker-based development environment that fills these two gaps:

Secret hiding: Specific files don't exist in AI's filesystem — not blocked, not filtered, just absent
Cross-container access: AI can check logs and run tests in other containers through a controlled gateway

It's complementary to existing tools. You can use Claude Code's sandbox inside the AI Sandbox for defense in depth.

How Secret Hiding Works

The trick is surprisingly simple: Docker volume mounts.

# docker-compose.yml
volumes:
  # AI sees an empty file instead of real .env
  - /dev/null:/workspace/my-app/.env:ro

tmpfs:
  # AI sees an empty directory instead of real secrets
  - /workspace/my-app/secrets:ro

When AI runs inside the container, it literally cannot see the real files. They don't exist in its filesystem. But other containers — the ones actually running your app — mount the real files normally.

AI Sandbox (where AI runs)
├── my-app/
│   ├── src/           ← AI can read and edit all code
│   ├── .env           ← Empty (mounted from /dev/null)
│   └── secrets/       ← Empty directory (tmpfs)

API Container (where your app runs)
├── my-app/
│   ├── src/           ← Same code
│   ├── .env           ← Real secrets
│   └── secrets/       ← Real private keys

No runtime agents scanning for secrets. No AI configuration that could be bypassed. The secrets simply don't exist in AI's world.

The risk with this approach is forgetting to hide a file. To catch that, the sandbox runs startup validation that automatically checks whether your AI tool's deny rules (e.g., .claude/settings.json) and your docker-compose.yml volume mounts are in sync. If a secret file is blocked in one but not the other, you get a warning on startup — before AI ever sees it.

How Cross-Container Access Works

Hiding secrets creates a new problem: AI can't access other containers for debugging. That's where DockMCP comes in.

DockMCP is an MCP (Model Context Protocol) server that runs on the host OS and acts as a controlled gateway between the AI sandbox and other Docker containers.

AI Sandbox  →  DockMCP (host)  →  API Container
  "show me       checks            returns last
   the logs"     security policy   100 log lines

AI can:

Read logs from any allowed container
Run whitelisted commands (like npm test)
Check resource usage (CPU, memory)
Inspect container configuration

AI cannot:

Start or stop containers
Access files outside allowed paths
Run arbitrary commands
Bypass the security policy

The security policy is defined in a simple YAML file:

security:
  mode: "moderate"
  allowed_containers:
    - "my-api-*"
    - "my-web-*"
  exec_whitelist:
    "my-api":
      - "npm test"
      - "npm run lint"
  blocked_paths:
    - "/etc/shadow"
    - "**/.env"

DockMCP also automatically masks sensitive data (passwords, API keys, tokens) in log output and command results, so even when AI reads logs from other containers, secrets don't leak through.

For the full configuration reference, see the DockMCP documentation.

Architecture Overview

┌─────────────────────────────────────────┐
│ Host OS                                 │
│                                         │
│  DockMCP Server (:8080)                 │
│    ├── Security policy enforcement      │
│    └── Container access gateway         │
│                                         │
│  Docker Engine                          │
│    ├── AI Sandbox                       │
│    │   ├── Claude Code / Gemini / etc.  │
│    │   └── secrets → hidden             │
│    │                                    │
│    ├── API Container                    │
│    │   └── secrets → real files         │
│    │                                    │
│    └── Web Container                    │
└─────────────────────────────────────────┘

What This Looks Like in Practice

Here's a real debugging session. I ask AI to help investigate a failing API endpoint:

Me: The /api/notes endpoint returns 500. Can you check the API logs?

AI uses DockMCP to fetch logs from the API container:

AI: I can see the error in the logs. There's a JWT verification failure at line 42 of auth.js. The token format changed after a recent update. Let me check the code...

AI reads the auth middleware code (visible in the sandbox), identifies the bug, and proposes a fix. It never sees the JWT secret key (hidden via volume mount), but it doesn't need to — it can see the code and the error logs.

Me: Looks good. Run the tests to make sure it passes.

AI runs npm test via DockMCP in the API container and confirms all tests pass.

The AI had everything it needed to debug and fix the issue, without ever accessing a single secret.

How to Try It

Minimal Setup (Sandbox Only)

If you just want secret hiding without cross-container access:

git clone https://github.com/YujiSuzuki/ai-sandbox-dkmcp.git
cd ai-sandbox-dkmcp
code .
# Cmd+Shift+P → "Dev Containers: Reopen in Container"

Edit docker-compose.yml to hide your secret files, and you're done.

Full Setup (Sandbox + DockMCP)

# 1. Clone and enter
git clone https://github.com/YujiSuzuki/ai-sandbox-dkmcp.git
cd ai-sandbox-dkmcp

# 2. Start DockMCP on host OS
cd dkmcp
make install
dkmcp serve --config configs/dkmcp.example.yaml

# 3. Open DevContainer in VS Code
code .
# Cmd+Shift+P → "Dev Containers: Reopen in Container"
# Or use the CLI sandbox (no VS Code needed):
# ./cli_sandbox/claude.sh or ./cli_sandbox/gemini.sh

# 4. Register DockMCP as an MCP server (inside the container)
claude mcp add --transport sse --scope user dkmcp http://host.docker.internal:8080/sse
# Or for Gemini CLI:
gemini mcp add --transport sse dkmcp http://host.docker.internal:8080/sse

The repo includes a demo application (SecureNote) so you can see the full flow in action. For detailed setup instructions, troubleshooting, and connection verification, see the README.

Honest Limitations

I want to be upfront about what this does and doesn't do:

Local development only. DockMCP has no authentication yet, so it's designed for local use only. I'd like to add authentication in the future, but no timeline has been set.
No network restriction by default. AI can still make outbound HTTP requests. You can add network restrictions using Anthropic's official firewall script or Docker network policies.
Docker required. The volume mount approach means you need a Docker-compatible runtime. No Docker, no secret hiding.
Only tested on macOS. It should work on Linux and Windows, but I haven't verified it.
Not a replacement for proper secrets management. This is a development-time protection layer. Use HashiCorp Vault, AWS Secrets Manager, etc. for production.
Complementary, not competing. This works alongside Claude Code's sandbox and Docker AI Sandboxes. Use them together for defense in depth.

Why This Matters

85% of developers now use AI coding tools (JetBrains, 2025). AI writes 29% of new code in the US. These tools aren't going away — they're becoming the default way we write software.

But the security model hasn't caught up. We give AI full read access to our projects and hope for the best. When something leaks, we rotate keys and move on.

We can do better. The approach doesn't have to be complicated:

Isolate AI in a container so secrets can be hidden at the filesystem level
Provide controlled access to other containers for debugging
Define explicit security policies for what AI can and cannot do

The AI Sandbox + DockMCP template is one implementation of this idea. Hit "Use this template" on GitHub to start your own.

The goal isn't to restrict AI — it's to let AI work freely in a space where secrets simply don't exist.

AI Sandbox + DockMCP is open source (MIT License). Contributions and feedback are welcome on GitHub.