First Steps in Isolating the Execution Environment to Use Claude Code to the Fullest Safely

I'm Kazue from the Manufacturing Business Technology Department.

At the Claude Code Seminar: AI-Driven Development Security Edition – Risks That Settings Alone Can't Prevent, and the Next Step: Isolating the Execution Environment held on September 1, 2026, I gave a talk titled "The First Step in Isolating the Execution Environment to Use Claude Code Safely and Thoroughly." Thank you to everyone who attended.

This article is a restructured version of that talk for the blog. Note that the content is current as of September 2026. In particular, Claude Code on the Web is a feature in research preview, so please be aware that its specifications may change in the future.

What I'll Talk About

1. The purpose of execution environment isolation: deciding which risk to address
   • First, I'll explain why isolating the execution environment is necessary and what its purpose is.
2. Introducing three isolation methods, and the first step
   • I'll introduce three concrete isolation methods. After that, I'll suggest a first step.

Let's start with the purpose of isolation.

The Purpose of Execution Environment Isolation: Deciding Which Risk to Address

Let me start with the conclusion. This time, I considered execution environment isolation with the goal of minimizing the damage scope of information leaks caused by supply chain attacks.

You might think, "That's a pretty narrow purpose" or "That doesn't seem to have much to do with Claude Code," but I'll explain that in due course.

First, Narrow Down to One Risk to Address

There are various conceivable risks in using AI coding agents.

• Leakage of confidential information
• High-cost usage of AI coding agent tools
• Unintended high-cost usage of cloud or SaaS
• Generation of vulnerable code
• Deletion of existing resources
• Increase in cognitive debt
• and more

It's difficult to deal with all of these at once, so I thought we needed to narrow down the risk to address first.

Our department (the Manufacturing Business Technology Department) does client work, mainly supporting customers in the manufacturing industry, and we often handle our customers' confidential information. We considered that leaking such confidential information would damage customer trust the most, so we made confidential information leakage the top-priority risk to address.

Next, Narrow Down to One Route to Address

There are also multiple conceivable routes for information leakage.

• Human error by developers (tool misconfiguration, etc.)
• AI malfunction
• Supply chain attacks (device compromise through malware installation)
• and more

Here too, it's hard to address every route at once, so we narrow down which one to prevent. This time, we chose supply chain attacks.

What Is a Supply Chain Attack?

A supply chain attack exploits the process (the supply chain) through which software reaches its users, injecting malicious code into legitimate software. For developers, the most familiar route is OSS packages published on npm, PyPI, and the like.

The typical flow is as follows.

1. The attacker hijacks a maintainer's account
2. They publish a new version containing malware
3. Malware gets into the device of a developer who installs it, via a script that runs automatically at install time
4. The device is compromised, resulting in damage such as information leakage

Why We Should Address Supply Chain Attacks

There are two reasons.

1. Because AI-driven development has increased the number of OSS package installations by orders of magnitude
2. Because large-scale attacks have been occurring frequently in recent years

I'll explain them in order.

Reason ①: The Number of OSS Package Installations Has Increased by Orders of Magnitude

Now that AI agents do the development, compared with when humans did it, the number of tasks has increased, parallel execution has become normal, and npm install and npx run for each one of them. And humans are no longer looking at what got installed. You might still be able to check the OSS packages you use directly, but once you include the other OSS packages that those packages use internally, it is no longer realistic for a human to trace everything.

More installations mean more incidents of damage.

Reason ②: Large-Scale Attacks Are Occurring Frequently

In recent years, large-scale supply chain attacks have occurred every few months. Here are the main ones in chronological order.

• August 2025 Nx "s1ngularity": the first attack to weaponize AI coding agents (Snyk, GitGuardian)
• September 2025 chalk / debug compromise: malware injected into a group of packages with over 2 billion combined weekly downloads (Wiz)
• September 2025 Shai-Hulud: the first self-replicating npm worm, infecting over 500 packages (CISA)
• November 2025 Shai-Hulud 2.0: returned on a scale of hundreds of packages (Microsoft Security Blog)
• March 2026 axios compromise: a standard package with 100 million weekly downloads was compromised (Wiz)
• April–June 2026 Mini Shai-Hulud / Miasma: targeting AI agent settings and credentials (vorlon.io, Microsoft Security Blog)
• May 2026 TanStack and other compromises: over 170 packages across npm / PyPI were compromised (Orca Security)

These are no longer rare events, and it's clear that developers' devices are being targeted. Here I'll introduce two cases.

Case ①: The axios Compromise — Things You Use Normally Get Contaminated

This incident occurred on March 31, 2026, with axios, an HTTP client with about 100 million weekly downloads. A maintainer's npm account was hijacked, and a malicious version was published. Through a script that runs automatically at install time (postinstall), a remote access trojan (RAT) became resident on the device. According to the official axios postmortem, the malicious version was available for about 3 hours, and devices that installed it during that time were compromised (official axios postmortem, Wiz).

It's a case where a device is taken over just by running npm install.

Case ②: AI Agents Became a "Weapon" for Malware

This is the Nx "s1ngularity" attack of August 2025. Malware was injected into the npm package Nx, and its postinstall stole credentials from the device. At that time, the attackers launched AI tools already installed on the device, such as Claude Code / Gemini CLI / Amazon Q, with flags that disable safety mechanisms, and made the AI itself search for confidential files.

According to GitGuardian's primary data, 2,349 credentials were detected across 1,079 repositories (GitGuardian, Snyk).

It's a case showing that, from the attacker's perspective, a logged-in agent becomes an "authenticated tool that can do anything."

Two Categories of Countermeasures: Prevention and Isolation

Countermeasures can be broadly divided into two.

• Prevention (proactive measures): Don't let malware in. There are widely published methods that are effective, such as settings that prevent installing packages immediately after release (npm's min-release-age, etc.) and malware-checking tools (Takumi Guard, Safe Chain). If you haven't done so yet, please do.
• Isolation (reactive measures): Minimize the damage even if malware gets in. This is the last line of defense when prevention is bypassed.

Prevention is effective, but we need to think about the next measure on the assumption that it will be bypassed. That is isolation.

When doing client work like our department does, information from multiple customers can be mixed on a single device. If such a device is compromised by a supply chain attack in one customer's project, the information of other customers will be taken completely as well. We want to avoid this, so we aim to minimize the damage scope, that is, to ensure that even if we are compromised, we lose only that project's information.

Conditions for Information Leakage and the Concept of "Walls"

Before introducing the three isolation methods, let's organize the conditions under which information leakage occurs.

Two elements are needed for information leakage to occur.

1. Malware can reach the confidential information
2. Malware can send that confidential information outside

What execution environment isolation targets this time is the first one: narrowing the scope of what malware can "reach." In this article, we call this a wall.

Note that each isolation method described below can sometimes also supplementarily address the second part, "sending outside," so I'll touch on that as well.

Three Walls: Where to Build Them

This time, I'll introduce three methods that differ in where the wall is built. They can be classified into three layers by where the wall is built (inner → outer).

The further out the wall, the wider the range it can protect. And there is one principle common to all three.

A wall can only protect what is placed outside the wall. Even for things brought inside the wall, you may be able to reduce damage by limiting where they can be sent, but it's safer to treat them as something that will be stolen. The important point is to bring as little unnecessary stuff as possible inside the wall.

Wall ①: Bash sandbox — Protecting the AI's Command Execution

This is Claude Code's built-in OS-level sandbox. You can configure it from /sandbox, and it enforces a boundary on the commands Claude executes and all their descendant processes. Because it can restrict write destinations and network access (where data can be sent), malware executed by the postinstall of npm install may also be confined inside the wall (Configure the sandboxed Bash tool - Claude Docs).

However, the default settings leave holes, so you need to tighten them to a stricter configuration. A representative one is the bypass route. When a command fails because of the sandbox, Claude Code may retry it outside the sandbox with the dangerouslyDisableSandbox parameter, and this is enabled by default. You can disable it with sandbox.allowUnsandboxedCommands: false.

※ Added 2026/09/18: I've summarized Bash sandbox configuration examples in the following entry.

• Claude Code's Bash sandbox lets credentials be read if you just enable it | DevelopersIO

The Bash sandbox is easy to start using, but honestly, it's a bit lacking from the viewpoint of supply chain attack countermeasures. That's because it only protects while the AI is running commands. Everything else, such as a human running npm run dev in their own terminal or an IDE loading node_modules, the "stages where humans run things," falls outside the wall and is defenseless. And there is also malware that triggers at such "stages where humans run things."

As a method that isolates even such timings, I'll introduce the next wall.

Wall ②: Dev Container — Confining the Whole Development Environment

This is a method of confining the development environment inside a container for each project. It can be used transparently from VS Code or Claude Code, and it limits what can be stolen to "only what you brought into that container." The advantage is that the "stages where humans run things" that the Bash sandbox couldn't protect, such as IDE extensions, launching apps, and running tests, can also be included inside the wall.

https://dev.classmethod.jp/articles/setup-claude-code-in-devcontainer/

There are three points to note.

• Mounted directories and passed environment variables can't be protected, so it's important to design things so that what you bring into the container is minimal
• By default, the network is wide open. You need your own implementation to limit where data can be sent, and Anthropic has published a reference implementation (init-firewall.sh) on GitHub, which you can use as a reference
• The wall may be breached. Considering that beyond the breach lie other customers' confidential information, it can be said to be somewhat fragile. Examples of "the wall being breached" are as follows.
  • In the past, there have been techniques to escape from a container by exploiting vulnerabilities in the kernel/container runtime (such as runc's CVE-2019-5736 and CVE-2024-21626).
  • Misconfiguration.
    In DevContainer (the VSCode extension), the local device's Git credentials are by default usable from inside the container. Therefore, if the container is compromised, the Git credentials may be abused.
    Also, if you want to use another container inside the DevContainer (for example, to use an MCP server provided as a container), adopting a so-called DooD (Docker outside of Docker) configuration effectively gives the DevContainer access to the entire local device (host device).
    • Sharing Git credentials with your container
    • Security Risks of Docker outside of Docker (DooD): Why Is "Socket Sharing" Dangerous? | DevelopersIO

Wall ③: Claude Code on the Web

This is a method of moving the execution environment itself off your device. Because Claude Code runs on an Anthropic-managed cloud VM, the only thing you do on your local device is give the initial instruction, and nothing actually runs there. Even if you suffer a supply chain attack, only that environment in the cloud is compromised (Use Claude Code on the web - Claude Docs).

The setting to "limit where data can be sent," which required your own implementation in Dev Container, is also provided as standard. It's a simple setting in a domain-list format where you just pick from four levels (None / Trusted / Full / Custom) in the UI. The default is Trusted, which allows only what's needed for development, such as various package registries and GitHub (Configure cloud environments - Claude Docs). In other words, even when used in the default state, a certain level of security can be said to be ensured.

Another good point of Claude Code on the Web is the developer experience. My impression is that it's not a tool you have to put up with for the sake of security.

• When starting a session: you just choose a repository. There's no need to clone the repository locally or set up an environment
• While it's running: work continues even if you close your PC. Even if you run many sessions in parallel, all of them run on cloud VMs, so the load on your local PC doesn't increase. You can also check progress from your smartphone and give instructions from there
• After it finishes: you receive the results as a pull request. For each session, it creates a branch, stacks commits, pushes to the GitHub repository, and even creates the pull request automatically. If you add review comments to that pull request, Claude picks them up and proceeds all the way to making the fixes

On the other hand, there are also prerequisites you should check before using it.

• It is a feature in research preview, and its specifications may change in the future
• It can't be used via Amazon Bedrock or Google Vertex AI
• Before using it for customer projects, you need to check whether the contract allows placing code on an external cloud
  • If this is a concern, an option to run the execution environment on your own managed infrastructure has recently appeared, so please consider that as well
    • Claude Code's Self-Hosted Environment Feature Arrives: I Tried Using an EC2 Instance as the Execution Environment | DevelopersIO
• Cloning / PR creation assumes GitHub
• Poorly suited development: anything that requires connecting to physical devices, internal networks, or heavy environment setup
• Some settings, such as user-scope settings, can't be brought over

Choosing Among the Three Walls

My top recommendation is ③, Claude Code on the Web. I think a good approach is to move as much work off the device as possible, and protect the remaining work with the Bash sandbox and Dev Container.

The First Step: Run One Task on Claude Code on the Web

There is one principle. A wall can only protect what is placed outside the wall, so reduce the amount you bring in, and if possible, run things outside your device.

As a first step, I suggest first running one task on Claude Code on the Web. The procedure is as follows (Get started with Claude Code on the web - Claude Docs).

1. Go to claude.ai/code and log in
2. Connect your GitHub account
3. Create an environment (configure the VM settings such as network access)
4. Select the environment you created and start a session ↓

After that, you can get started just by entering a prompt and running it. Please give it a try.

Summary

• The purpose of execution environment isolation is to minimize the damage scope of information leaks caused by supply chain attacks. Since AI coding agents carry various risks, the starting point is to narrow down the risk and route to address first
  • ※ "Execution environment isolation" can also be useful for minimizing damage from other risks such as prompt injection. However, dealing with many risks at once makes the discussion complicated, so this time I've narrowed it down to the risk of information leakage from supply chain attacks.
• Two conditions, "can reach" and "can send out," are needed for information leakage to occur, and execution environment isolation corresponds to a wall that narrows the scope of what can be "reached"
• I introduced three walls: ① Bash sandbox (protecting the AI's command execution), ② Dev Container (confining the whole development environment), ③ Claude Code on the Web (moving the execution environment itself off the device)
• There is one principle. A wall can only protect what is placed outside the wall. Reduce the amount you bring in, and if possible, move it off the device
• Please start by running one task on Claude Code on the Web

References

• Configure the sandboxed Bash tool - Claude Docs
• Development containers - Claude Docs
• anthropics/claude-code - .devcontainer(init-firewall.sh)
• Use Claude Code on the web - Claude Docs
• Configure cloud environments - Claude Docs
• Get started with Claude Code on the web - Claude Docs
• The npm Threat Landscape: Attack Surface and Mitigations - Unit 42
• Widespread Supply Chain Compromise Impacting npm Ecosystem - CISA
• Shai-Hulud 2.0: Guidance for detecting, investigating, and defending against the supply chain attack - Microsoft Security Blog
• Post Mortem: axios npm supply chain compromise - GitHub Issue #10636
• Wiz: axios npm compromised in supply chain attack
• Weaponizing AI Coding Agents for Malware in the Nx Malicious Package - Snyk
• The Nx "s1ngularity" Attack: Inside the Credential Leak - GitGuardian
• vorlon.io: Mini Shai-Hulud npm supply chain AI coding tools
• TanStack and 160+ npm/PyPI Packages Compromised in Supply Chain Worm Attack - Orca Security