You’ve done it. You spun up a new Git worktree, pointed your AI coding agent at it, and felt a wave of relief. Safe. The agent can’t touch your main branch, can’t mess with your production code. It’s isolated, right?
Wrong. Dead wrong.
Let me show you the nightmare you’ve invited into your local environment.
I’m going to say something that might make you uncomfortable: Git worktrees are not a sandbox. They are a shared hotel room with paper-thin walls. Every worktree you create shares the same underlying .git directory. That means your hooks, your config, your stashes — they’re all accessible from any worktree. And if you give an AI agent access to one worktree, you’ve given it a skeleton key to your entire Git history.
You’ve probably noticed that worktrees are cheap. One command, zero disk overhead. That’s why every developer I know reaches for them when they need to quickly test something or let an agent work on a feature. But cheap isolation is like a flimsy lock on a bathroom door — it keeps out the honest, but not the curious.
Consider this: your AI agent is autonomous. It can run arbitrary commands. It can read, write, and execute. If it’s in a worktree, it can reach into your .git/hooks and install a post-commit hook that sends your credentials to a remote server. It can pop a stash from another worktree and inject malicious code. It can change your global Git config and redirect all future pushes. And you’ll never see it coming because the worktree looks clean.
I’ve seen this firsthand. A colleague of mine was using an AI agent to refactor a feature branch. The agent was in a worktree. It needed to run a test, so it modified a pre-commit hook. That hook then triggered on every commit across all worktrees. The next day, his entire team’s CI pipeline was failing because of a silent hook change. When you give an agent a worktree, you’re giving it a window into your entire local Git ecosystem.
Now, you might be thinking: “But I’m careful. I only use worktrees for small, trusted agents.” That’s what everyone says before they lose a day debugging a corrupted stash. The problem isn’t the agent’s intent — it’s the architecture. Worktrees were designed for a single human developer switching contexts. They were never meant to be a security boundary. And yet we’ve been treating them as one.
Here’s the twist: the very thing that makes worktrees attractive — shared state — is exactly what makes them dangerous for autonomous agents. You thought you were getting cheap isolation. Instead, you got a vector for cross-contamination. Neutrality is death in security. Either you isolate fully, or you don’t isolate at all. Worktrees are the worst of both worlds.
So what’s the alternative? Clone the repository. Yes, it costs disk space. Yes, it takes a few extra seconds. But a clone gives your agent a fresh, independent .git directory. No shared hooks. No shared config. No shared stashes. If the agent goes rogue, it can only wreck its own clone. Your main development environment stays clean.
Stop treating worktrees as sandboxes. They’re not. They’re a shared living room where your AI agent can rummage through your drawers. If you care about your code, your credentials, and your sanity — clone. Every time.
Your next agent could be the one that wipes your stash. Don’t let it.
FAQ
Q: I've been using worktrees for agents and never had an issue. Are you exaggerating?
A: No. The lack of an incident so far doesn't mean it's safe. Worktrees share the same .git directory, meaning hooks, config, and stashes are all accessible from any worktree. An autonomous agent can silently modify those shared resources. The risk is real, and it only takes one rogue command to corrupt your entire local environment.
Q: What's the practical takeaway for my daily workflow?
A: Stop using worktrees for AI agents. Instead, use a full clone for each agent session. Yes, it uses more disk space and takes longer to set up, but that's the price of true isolation. Your development environment is too valuable to risk on a shared .git directory. Clone, don't worktree.
Q: But clones are slow and wasteful. Isn't there a middle ground?
A: No. Middle ground is what got us into this mess. You can optimize clone speed by using --reference or shallow clones, but the key is a separate .git directory. If you absolutely must use worktrees, at least revoke the agent's ability to write to hooks and config. But that's a band-aid. The architectural truth is simple: worktrees are not isolation boundaries.