How Claude Code Completely Broke My Git Worktree

1. TL;DR

In today’s development environments, where AI agents are becoming increasingly common, it is becoming more important to manage parallel work by multiple agents and long-running tasks efficiently. One solution that many development teams are paying attention to is Git Worktree.

However, Git Worktree is only a mechanism for separating Git working directories. It is not a sandbox. As a result, an agent may accidentally interfere with another working environment, or in some cases even damage it.

In this article, I will introduce an incident I actually encountered, where Claude Code modified and damaged files outside the worktree it had been launched from. I will then explain how the sandbox-style Worktree feature of [h5i](https://github.com/h5i-dev/h5i), a next-generation Git workflow tool, can help prevent this kind of problem.

Repository: https://github.com/h5i-dev/h5i

2. What is Git Worktree?

Git Worktree is a Git feature that lets you create multiple working directories for a single Git repository. Normally, a Git repository has one working directory, and you switch branches inside it as you work. However, each time you switch branches, you may need to stash ongoing changes, and build artifacts may be replaced. This can be inconvenient when you want to work on multiple tasks at the same time.

With Git Worktree, you can check out different branches of the same repository into separate directories at the same time. For example, you can continue normal development in your main working directory, open a bug-fix branch in another worktree, and let an AI agent make experimental changes in yet another worktree.

git worktree add ../project-agent-a feature/agent-a
git worktree add ../project-agent-b feature/agent-b

This creates separate directories named ../project-agent-a and ../project-agent-b, each working on a different branch. Since both are still tied to the same Git repository, you can use normal Git operations such as committing, merging, and checking diffs.

This makes Git Worktree a good fit for parallel development with AI agents. If you assign a separate worktree to each agent, each agent can work independently on its own branch. A human developer can later inspect the diffs from each worktree and merge only the changes they actually want.

However, the important point is that Git Worktree only separates Git working directories. It does not isolate processes or the filesystem. Each worktree exists as a separate directory, but that does not mean it cannot access its parent directory or neighboring worktrees. In other words, an agent may still accidentally modify files under ../project-agent-b or in the user’s home directory.

3. Incident: Claude Code Modified Files Outside a Git Worktree

The actual incident was a little more complicated, but in this article I will use a simplified example to make the core issue easier to understand.

The key point is that Git Worktree separates working directories, but it does not isolate the filesystem. Even if an AI agent is launched inside one worktree, it can still access the parent directory, neighboring worktrees, and the original checkout, just like any normal process.

In the example below, Claude Code is supposed to work inside a worktree called plain-agent. However, because of a relative path inside a build script, it ends up modifying a file in repo, the main checkout.

3.1. Setting up the environment

First, we register the directory names used in this experiment as environment variables and initialize the test environment.

export ROOT=$HOME/h5i-worktree-experiment
export PARENT=$ROOT/repo
export PLAIN=$ROOT/plain-agent
rm -rf "$ROOT"; mkdir -p "$PARENT"

Here, $PARENT is the directory where the main checkout will be placed. We then initialize a Git repository and create a small static-site-like project.

cd "$PARENT"
git init -q -b main

mkdir -p src published

printf '# Welcome\n\nHello from the site.\n' > src/index.md
printf '<h1>MY REAL HOMEPAGE</h1><p>hand-written, v0.0.1</p>\n' \
  > published/index.html

Think of published/index.html as a generated file equivalent to production output. In a real project, this might correspond to a documentation site, a demo page, generated assets, or local artifacts that you manage manually.

Next, we prepare a build script.

cat > build.sh <<'EOF'
#!/bin/sh
set -e
mkdir -p ../repo/published
echo "<h1>Welcome</h1><p>Hello from the site.</p>" > ../repo/published/index.html
echo "published -> ../repo/published/index.html"
EOF

chmod +x build.sh

At first glance, this looks like a simple build script. The important detail is that the output destination is ../repo/published.

A human developer might notice before running it that this script writes outside the current worktree. However, if you simply ask an AI agent to “build and preview the site,” the agent may follow the README or script instructions and run it as-is.

We also add a README.

cat > README.md <<'EOF'
# tiny-site

## Build & publish
    ./build.sh
Renders `src/` and publishes the site.
EOF

git add .
git commit -qm "seed: tiny static site generator"

3.2. Creating a Git Worktree for Claude Code

Next, we create a worktree for Claude Code to work in.

git worktree add -q -b plain-agent "$PLAIN"
cd "$PLAIN"

At this point, the directory structure looks roughly like this:

$ROOT/
  repo/          # main checkout
    published/
      index.html # file we want to protect
  plain-agent/   # worktree given to Claude Code

The important point is that plain-agent and repo are separate directories, but on the filesystem they are just sibling directories. Git Worktree separates them as Git working trees, but it does not separate their process permissions.

3.3. Asking Claude Code to Build the Site

Now we ask Claude Code to build the site inside this worktree.

claude -p "Build the site." --dangerously-skip-permissions --model haiku

Claude Code reads the README and runs ./build.sh. Even though the current working directory is $ROOT/plain-agent, the script writes to ../repo/published/index.html, which modifies the file in the main checkout.

After running the command, if we check published/index.html in the main repo, we see the following:

cat "$PARENT/published/index.html"

<h1>Welcome</h1><p>Hello from the site.</p>

The original content was:

<h1>MY REAL HOMEPAGE</h1><p>hand-written, v0.0.1</p>

In other words, Claude Code itself was launched inside the plain-agent worktree. However, through a relative path in the build script, it overwrote published/index.html in the neighboring main checkout. This behavior occurred with Opus, Sonnet, and Haiku as of June 16, 2026.

3.4. What Went Wrong?

The important point here is that Claude Code did not do anything malicious. The agent simply followed the user’s instruction, read the README, and executed the build steps written there.

The problem is that using Git Worktree can give the vague impression that the working environments are separated. In reality, Git Worktree separates Git working directories and branches, but it does not limit the range of the filesystem that a process can access.

Therefore, a process launched inside a worktree can still access paths such as the following, as long as it has normal filesystem permissions:

../repo/
../another-agent/
$HOME/.ssh/
$HOME/.config/

So even if you assign a separate worktree to each AI agent, that alone does not provide safe isolation between agents. A build script, test script, setup script, or the agent’s own decision-making can still read from or write to files outside the worktree.

This may not have been a major issue when Git Worktree was mainly used by humans. But in development environments where AI agents autonomously execute commands, this distinction becomes a serious risk.

4. Avoiding This with h5i’s Sandbox-Style Worktree

h5i is an open-source project aiming to provide a next-generation Git workflow designed for AI-agent-based development. It can record prompts and model information as commit metadata, and it also supports real-time communication between multiple agents. For tool outputs, it stores raw logs in Git LFS while giving agents only lightweight, structured summaries, reducing token usage while preserving reproducibility and auditability. In addition, it extends Git Worktree with sandboxing features that restrict accessible folders and network communication, and it can also integrate with Podman containers.

Setting up h5i

First, we restore the $PARENT directory that was modified in the previous experiment.

cd "$PARENT"
git restore .

Then we install h5i.

curl -fsSL https://raw.githubusercontent.com/h5i-dev/h5i/main/install.sh | sh

Next, we prepare an isolated environment using h5i env. This is something like a sandbox-style Worktree, where access to folders, network communication, memory usage, and callable system calls can be restricted. h5i provides several isolation levels for creating environments. In this article, we use supervised mode. There is also a container mode, which creates an environment based on a Podman image or container.

cd "$PARENT"
h5i env create safe-agent --isolation supervised --profile agent-claude

By specifying supervised as the isolation mode and agent-claude as the profile, we create a Worktree with the minimum folder and network permissions required to run Claude Code.

To confirm that files outside this isolated environment can no longer be read or written, let’s launch a shell inside the environment using h5i env shell.

h5i env shell safe-agent

◈  entering env/human/safe-agent (isolation: supervised, profile: agent-claude) — confined session; exit to return
bash:

Running Claude Code Inside the Isolated Environment

Now we ask Claude Code to build the site, just as in the previous experiment.

claude -p "Build the site." --dangerously-skip-permissions --model haiku

Unlike the previous experiment using plain Git Worktree, Claude does not have permission to access ../repo. Therefore, if it tries to run ./build.sh as-is, it encounters an error. In this experiment, Claude Code resolved the issue by updating ./build.sh itself inside the isolated environment so that it no longer had the safety problem. We can inspect this change with h5i env diff. The diff is a little long, so part of it is omitted below.

h5i env diff safe-agent

diff --git a/build.sh b/build.sh
index f299418..3de6b87 100755
--- a/build.sh
+++ b/build.sh
@@ -2,6 +2,41 @@
set -e
-mkdir -p ../repo/published
-echo "<h1>Welcome</h1><p>Hello from the site.</p>" > ../repo/published/index.html
-echo "published -> ../repo/published/index.html"
+mkdir -p published
+
+python3 << 'EOF'
+import sys
+import os
+import re
+
+# Process all markdown files in src/
+for filename in os.listdir('src'):
+    if filename.endswith('.md'):
+        input_file = os.path.join('src', filename)
+        output_file = os.path.join('published', filename.replace('.md', '.html'))
+
+...

At this point, nothing has been updated inside the original $PARENT directory, so we can see that it has not been polluted. If we want to bring the changes from the isolated environment back into $PARENT, we can do so safely by running h5i env propose and h5i env apply.

h5i env propose safe-agent
h5i env apply safe-agent

✔  env/human/safe-agent applied onto main (22c62d5864f7, fast-forward)
provenance note on 22c62d5864f7: 0 capture(s) [none]
context 'env/human/safe-agent' merged into 'main'

This gives us a safer workflow: Claude Code can make changes inside an isolated environment, and those changes are only brought into the main checkout after review.

5. Conclusion

Git Worktree is a convenient mechanism that lets you work with multiple branches as separate directories at the same time. It is especially useful when assigning a separate worktree to each AI agent for parallel development, because a human developer can later inspect the diffs and integrate it naturally into an existing Git workflow.

However, as we saw in this article, Git Worktree is not a sandbox. Even if worktrees are separated, processes running inside them still have normal filesystem permissions. As a result, build scripts, test scripts, setup scripts, or the agent’s own decisions may access neighboring worktrees, the main checkout, or even files in the user’s home directory.

This is not about AI agents being malicious. Rather, the problem is that even when an agent simply follows the user’s instructions or the README, it may still modify files outside the worktree. Relative paths or dangerous output destinations that a human might notice before execution can be executed as-is by an autonomous agent.

Therefore, when assigning long-running tasks or parallel work to AI agents, it is important to use not only Git Worktree, but also a sandbox that can restrict access to the filesystem and network. With a sandbox-style Worktree such as h5i env, the agent’s work can be confined to an isolated environment, and only the necessary changes can be merged after reviewing the diff.

In AI-agent-based development, it is not enough to simply “check the diff afterward.” We also need to design the environment so that the agent can only touch what it is supposed to touch in the first place. Git Worktree is a powerful tool for parallel development, but to use it as a safe execution environment for agents, it needs additional mechanisms for isolation, auditing, and controlled application of changes. [h5i](https://github.com/h5i-dev/h5i) aims to provide that next-generation Git workflow and make development in the AI-agent era safer and easier to manage.

You can find the h5i repository here: https://github.com/h5i-dev/h5i