Isolating Execution Environments for Safe and Thorough Use of Claude Code: First Steps

Manufacturing Business Technology Department's Kazue here.

At the Claude Code Seminar AI-Driven Development Security Edition: Risks That Can't Be Prevented by Configuration Alone, and the Next Step of Execution Environment Isolation held on September 1, 2026, I presented under the title "First Steps to Isolating Execution Environments for Safe and Thorough Use of Claude Code." Thank you to everyone who attended.

This article is a reorganized version of that presentation content for the blog. Please note that the content reflects the state of affairs as of September 2026. In particular, Claude Code on the Web is a feature in research preview stage, so please be aware that specifications may change in the future.

What We'll Cover

1. Purpose of Execution Environment Isolation: Deciding Which Risks to Address
   • First, I'll explain why execution environment isolation is necessary and its purpose.
2. Introduction to Three Isolation Methods, and First Steps
   • I'll introduce three specific isolation approaches, then suggest first steps to get started.

Let's start with the purpose of isolation.

Purpose of Execution Environment Isolation: Deciding Which Risks to Address

Let me state the conclusion upfront. For this discussion, I considered execution environment isolation with the goal of minimizing the scope of damage from information leaks caused by supply chain attacks.

You might think "that's a very narrow goal" or "it doesn't seem very related to Claude Code," but I'll explain that in due course.

First, Narrow Down to One Risk to Address

There are various risks to consider when using AI coding agents.

• Leakage of confidential information
• Excessive usage costs for AI coding agent tools
• Unintended high costs for cloud or SaaS
• Generation of code with vulnerabilities
• Deletion of existing resources
• Increase in cognitive debt
• And more

Since it's difficult to address all of these at once, I felt it was necessary to narrow down which risk to tackle first.

Our department (Manufacturing Business Technology Department) does client work primarily supporting manufacturing industry customers, and we frequently handle customers' confidential information. We determined that leaking such confidential information would be the greatest damage to customer trust, and made confidential information leakage the highest-priority risk to address.

Next, Narrow Down to One Pathway to Address

There are also multiple pathways through which information leaks can occur.

• Developer human error (such as tool misconfiguration)
• AI malfunction
• Supply chain attacks (device compromise through malware installation)
• And more

It's also difficult to address all pathways at once, so we narrow down which one to prevent. This time, we chose supply chain attacks.

What Are Supply Chain Attacks?

A supply chain attack is an attack that exploits the process (supply chain) by which software reaches users, mixing malicious code into legitimate software. For developers, the most familiar pathway is OSS packages published on npm, PyPI, and similar repositories.

The typical flow goes like this.

1. An attacker hijacks a maintainer's account
2. A new version with injected malware is published
3. Through scripts that auto-execute at install time, malware infiltrates the device of a developer who installs it
4. The device is compromised, resulting in damage such as information leaks

Why Supply Chain Attacks Should Be Addressed

There are two reasons.

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

I'll explain each in turn.

Reason ①: OSS Package Installation Counts Have Increased by an Order of Magnitude

In today's world where AI agents do development, compared to when humans did development, the number of tasks has increased, parallel execution has become normal, and npm install or npx runs in each and every one of them. And humans are no longer watching what gets installed. Even just the OSS packages being used directly might still be checkable, but when you include the other OSS packages that those OSS packages use internally, it becomes unrealistic for humans to track everything.

As installation counts increase, so does the number of incidents.

Reason ②: Large-Scale Attack Incidents Are Occurring Frequently

In recent years, large-scale supply chain attacks have been occurring every few months. Here are the major 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 totaling over 2 billion weekly downloads (Wiz)
• September 2025, Shai-Hulud: The first self-propagating npm worm, infecting over 500 packages (CISA)
• November 2025, Shai-Hulud 2.0: Returned at 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 configurations and credentials (vorlon.io, Microsoft Security Blog)
• May 2026, TanStack and other compromises: Over 170 packages across npm/PyPI compromised (Orca Security)

This is clearly no longer a rare occurrence, and it can be said that developer devices are clearly being targeted. Let me introduce two cases from this list.

Case ①: axios Compromise — Commonly Used Packages Get Contaminated

An incident that occurred on March 31, 2026, involving axios, an HTTP client with approximately 100 million weekly downloads. A maintainer's npm account was hijacked, and a malicious version was published. Through a script (postinstall) that auto-executes at install time, a remote access trojan (RAT) was designed to take up permanent residence on the device. According to the official axios postmortem, the malicious version was live for about 3 hours, and devices that installed it during that time were compromised (axios official postmortem, Wiz).

This is a case where simply running npm install caused a device to be taken over.

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

This is the Nx "s1ngularity" from August 2025. Malware was injected into the npm package Nx, and postinstall stole credentials from the device. In doing so, a technique was used where AI tools already installed on the device—such as Claude Code / Gemini CLI / Amazon Q—were launched with safety mechanism disabling flags, causing the AI itself to search for sensitive files.

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

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

Two Categories of Countermeasures: Prevention and Isolation

Countermeasures can be broadly divided into two categories.

• Prevention (proactive measures): Keep malware from getting in. Methods widely published in the world—such as settings to avoid installing packages immediately after publication (npm's min-release-age) and malware checking tools (Takumi Guard, Safe Chain)—are effective. If you haven't implemented these yet, please do so.
• Isolation (reactive measures): Minimize damage even if malware gets in. This is the last line of defense when prevention is circumvented.

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

When doing client work like our department does, there are cases where information from multiple customers is mixed on a single device. If that device is compromised by a supply chain attack in one customer's project, the information of other customers could be taken wholesale as well. We want to avoid this, so we aim to minimize the scope of damage—meaning even if compromised, limit the loss to only the information from that project.

Conditions for Information Leaks to Occur and the Concept of "Walls"

Before introducing the three isolation methods, let me organize the conditions for information leaks to occur.

Two elements are needed for information leakage to occur.

1. Malware being able to reach confidential information
2. Malware being able to send that confidential information to an external destination

What we target with execution environment isolation this time is the first point—narrowing the range of "being able to reach." In this article, I'll call this a wall.

Note that each isolation method discussed later can sometimes additionally address the second point, "being able to send to external destinations," so I'll touch on that as well.

Three Walls: Where to Place Them

This time, I'll introduce three methods that differ in where the wall is placed. They can be classified into three layers based on where the wall is placed (from inner to 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 it. Even for things brought inside the wall, there is some possibility of reducing damage by restricting where they can be sent, but it's safer to treat them as potentially stolen. Keeping unnecessary things from being brought inside the wall as much as possible is an important point.

Wall ①: Bash Sandbox — Protecting AI Command Execution

This is Claude Code's standard OS-level sandbox. It can be configured from /sandbox, and enforces boundaries on commands executed by Claude and all their descendant processes. Since it can restrict write destinations and network access (destinations that can be sent to), malware executed through postinstall during npm install may also be contained inside the wall (Configure the sandboxed Bash tool - Claude Docs).

However, the default configuration has gaps remaining, so it needs to be tightened to a harder configuration. A representative example is bypass routes. When a command fails due to the sandbox, Claude Code may retry outside the sandbox with the dangerouslyDisableSandbox parameter, which is enabled by default. You can disable this by setting sandbox.allowUnsandboxedCommands: false.

Bash sandbox is easy to start using, but honestly speaking, it's a bit lacking when considered from the perspective of supply chain attack countermeasures. That's because it only protects when AI is executing commands. Other times—for example, when a human runs npm run dev in their own terminal, or when the IDE loads node_modules—are outside the wall and unprotected. And malware that activates at such "stages when humans operate" does exist.

As a method that includes isolation at such timing as well, let me introduce the next wall.

Wall ②: Dev Container — Containing the Entire Development Environment

A method of containing the development environment inside a container per project. It can be used transparently from VS Code or Claude Code, and limits what can be stolen to "only what was brought into that container." The advantage is that it can also include "stages when humans operate" inside the wall—such as running IDE extensions, launching applications, and running tests—which the Bash sandbox couldn't protect.

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

There are three points to be careful about.

• Mounted directories and passed environment variables cannot be protected, so designing to minimize what is brought into the container is important
• By default, network traffic passes through without restriction. Custom implementation to restrict destinations is needed, and Anthropic has published a reference implementation (init-firewall.sh) on GitHub that can be referenced
• There is a possibility of the wall being broken. Considering that beyond a broken wall there is confidential information from other customers, this can be said to be somewhat vulnerable. Examples of "the wall being broken" include:
  • There have been past methods of escaping from containers by exploiting kernel/container runtime vulnerabilities (such as runc's CVE-2019-5736, CVE-2024-21626, etc.).
  • Misconfiguration.
    In DevContainer (as a VS Code Extension), local device Git credentials are made available from inside the container by default. Therefore, if the container is compromised, there is a risk of Git credentials being exploited.
    Also, if you want to use another container inside DevContainer (e.g., wanting to use an MCP server provided as a container), adopting a so-called DooD (Docker outside of Docker) configuration essentially gives the DevContainer access to the entire local device (host device).
    • Sharing Git credentials with your container
    • Docker outside of Docker (DooD) Security Risks: Why "Socket Sharing" Is Dangerous | DevelopersIO

Wall ③: Claude Code on the Web

A method of moving the execution environment itself outside the device. Since Claude Code runs on an Anthropic-managed cloud VM, nothing actually runs on your local device—you only need to give the initial instructions. Even if a supply chain attack occurs, only that environment on the cloud gets compromised (Use Claude Code on the web - Claude Docs).

The "restricting destinations" configuration that required custom implementation with Dev Container is also built in as standard. It's a simple setting where you just choose from 4 levels (None / Trusted / Full / Custom) in the UI using a domain list format. The default is Trusted, which only allows things needed for development—such as various package registries and GitHub (Configure cloud environments - Claude Docs). In other words, even using it in the default state, a certain level of security is guaranteed.

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

• When starting a session: Just select a repository. There's no need to clone the repository locally or set up the environment
• While it's running: Work continues even when you close your PC. Even if you run many sessions in parallel, all of them execute on cloud VMs, so your local PC's load doesn't increase. You can check the work status from your smartphone and give instructions from there too
• After it's done: You receive the results as a pull request. It automatically handles everything from creating a branch for each session, accumulating commits, pushing to the GitHub repository, and creating a pull request. When you add review comments to that pull request, Claude picks them up and proceeds with making the corrections

On the other hand, there are also prerequisites to confirm before using it.

• It is a feature in research preview stage, and specifications may change in the future
• It cannot be used through Amazon Bedrock or Google Vertex AI
• Before using it for customer projects, you need to confirm whether your contract allows placing code on an external cloud
  • For those concerned about this point, an option of using self-managed infrastructure for the execution environment has recently emerged, so please consider this as well
    • Claude Code Self-Hosted Environment Feature Has Arrived. Tried Using an EC2 Instance as the Execution Environment | DevelopersIO
• Clone / PR creation assumes GitHub
• Development that's incompatible: Anything requiring physical device connection, internal network, or heavy environment setup
• Some settings, such as user-scope settings, cannot be brought in

How to Use the Three Walls

My top recommendation is ③ Claude Code on the Web. I believe a good approach is to progressively move work that can be done outside the device to the cloud, and protect the remaining work with Bash sandbox or Dev Container.

First Steps: Try Running 1 Task Through Claude Code on the Web

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

As a first step, I suggest trying to run just 1 task through Claude Code on the Web. The steps are as follows (Get started with Claude Code on the web - Claude Docs).

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

After that, just enter a prompt and run it to get started. Please give it a try.

Summary

• The purpose of execution environment isolation is to minimize the scope of damage from information leaks caused by supply chain attacks. Since there are various risks with AI coding agents, the starting point is first narrowing down the risk and pathway to address
  • ※ "Execution environment isolation" can also be useful for minimizing the impact of other risks such as prompt injection. However, since dealing with many risks at once makes the discussion complicated, this article focuses specifically on the risk of information leaks from supply chain attacks.
• For information leaks to occur, two conditions are needed: "being able to reach" and "being able to send out," and execution environment isolation acts as a wall to narrow the range of "being able to reach"
• Three walls were introduced: ① Bash sandbox (protecting AI command execution), ② Dev Container (containing the development environment entirely), ③ Claude Code on the Web (moving the execution environment itself outside the device)
• There is one principle. A wall can only protect what is placed outside it. Reduce what you bring in, and if possible, move it outside the device
• Please start by trying to run just 1 task through 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