Git | Bas Nijholt

Removing the guardrails and letting my coding agents loose

Tue, 22 Sep 2026 00:00:00 +0000

I have run coding agents in YOLO mode since I started using them in May 2025. I think it is the only way to parallelize work. Sometimes I have ten agents running at the same time, and clicking “approve” on every command they run would make that impossible.

What makes me comfortable with it is that models tend to do what you ask, and that you can keep them in an environment where they cannot do much harm. I don’t keep secrets within their reach, and above all I have very good backups. The last piece is a small set of hooks that block the few things I never want an agent to do on its own.

Why hooks and not AGENTS.md #

My system prompt has always told agents not to force-push or merge PRs. Some of them did it anyway.

The first time I really noticed was with Gemini 3 Pro in November 2025, which merged my PR and force-pushed to main. It happened a couple more times in the weeks after, as I parallelized more and asked more of the models. Three weeks later I had hooks for Claude Code and Gemini CLI that block these commands before they run. Codex did not support hooks yet. To my surprise, it did not need them: OpenAI’s models are extremely good at following instructions, and Codex never ignored an explicit rule in my AGENTS.md. Codex supports hooks by now, so it runs the same ones as the others.

Claude has been worse at following rules, and Gemini far worse still: absolutely dogshit. I only try Gemini now and then, and I have been disappointed every time. By now I don’t even try the latest Google models anymore.

I don’t think agents are ever purposely malicious. They try to do what you asked, but they can misinterpret it, and then they force-push or merge something. A rule in a Markdown file is a hope; a hook actually stops the command. Not that a hook would stop a malicious agent: it could put the blocked command in a Bash script and run that instead. What the hook does is tell the agent why I don’t want it, because every block comes with a short explanation:

git add -A is not allowed - add files explicitly to avoid adding unrelated untracked files

The models are well aligned, so once they know my intention, they respect it.

What I block #

All hooks live in my dotfiles, and I deliberately kept them simple. The detection logic is one Python module, git_guard.py, and the Claude Code, Codex, and Gemini CLI hooks all import it.

git commit --amend and git push --force. The unit I review is a PR. When I review a PR, I know I have reviewed it up to a certain commit, and later I only look at the diff of the new commits. Rewriting history breaks that.

Pushing to main. Everything happens in PRs. Inside a PR I don’t care how messy the history gets. I want the agent to push very often, so no work gets lost, and every commit has to be green, so each one is a snapshot I can go back to. The agent maintains its own development of the feature, and I have not written a commit message myself in a long time. When the PR is done, I squash merge it.

gh pr merge. The merge comes after my review, so it is mine to do.

git add -A. I often have unrelated untracked or unstaged files lying around. I work in many open source repositories, and some of those files should not be public, like deployment plans. This is the only block without an override.

sleep. This one is for Claude, and Opus 5 specifically, which I hate with a passion. It would run tests in the background and then sleep 300, badly overestimating how long the tests take, when a blocking tool call returns exactly when they finish.

The override #

Over time the models got more capable. I could parallelize more, and I trusted them to work on their own for longer. I noticed I was spending a significant fraction of my time clicking buttons and doing operations I had forbidden the agent to do, only to end up doing them myself.

So in July I added an override. When a hook blocks a command, the agent gets this hint:

If (and only if) the user has explicitly approved this exact action,
re-run the command prefixed with EXPLICITLY_USER_APPROVED_HOOK_OVERRIDE=1 to override this block.

Nothing checks whether I actually approved it. It is a soft gate, but it works because the agent now has to write down, in the command itself, that I approved the action. When it runs into the block without my approval, it becomes obvious to the agent that it has to ask me first.

git add -A stays hard-blocked, and a chained command cannot carry an override past it: EXPLICITLY_USER_APPROVED_HOOK_OVERRIDE=1 git commit --amend && git add -A is still rejected.

When the override was used without approval #

It has happened, mostly with GPT-5.6 Sol, which I used a lot at the time.

It used to be that you had to keep your context window short, because auto-compaction was lossy and produced poor summaries. Since around GPT-5.3, compaction works well enough that I keep a session going for as long as I am working on the same feature. So I would ask the agent to merge a PR early on, start a follow-up PR in the same session, and after a compaction the agent concluded that it should merge the new PR too. It did, without my approval.

The other case was my pr-review skill, by far my favorite skill that I wrote myself. I would tell the agent to run it and squash merge the PR only if the review approved it. A few times, the review found problems, the agent fixed them, and then it merged. What I meant was: merge if it is approved right away, and otherwise wait for me. Now I spell that out and end with “otherwise, wait for my instructions.”

Working from my phone #

The override matters most when I am away from my computer. On a month-long trip visiting family in Europe, I worked only from my phone, using my mobile coding workflow. Typing commands in a terminal on a phone is inconvenient, so I would rather say what I want and let the agent do it, including the merge. I have also built end-to-end encrypted voice calls to my agents over Matrix with MindRoom, and I am moving more toward that kind of voice-driven workflow.

Not much has changed #

I recently reread my first post on agentic coding from August 2025, and very little in it is outdated. The models are more capable, and I give them much larger scopes, but the way I work is mostly the same. The hooks are the main thing I added, and the override is how I loosened them again.

Parallel agentic coding made trivial with `agent-cli dev`

Tue, 13 Jan 2026 00:00:00 +0000

Table of contents

1. The “just use worktrees” problem #

Last week, I was chatting with a friend about my agentic coding workflow. I was sharing some of my best practices, and when the topic of parallel development came up, I said:

“Just use git worktrees with quickly installable environments.”

He stared at me blankly.

And then it hit me: for most developers who just git add, git commit, git push and don’t touch their environment setup once it works, this is not trivial. What seems obvious to me involves:

Understanding what git worktrees even are
Knowing the git worktree add command and its flags
Remembering to fetch before creating
Creating a sibling directory structure
Running your package manager’s install command
Copying over .env files
Setting up direnv or manually activating your virtual environment
Opening a new terminal tab
Navigating to the worktree
Finally launching your coding agent

That’s a lot of friction for something you want to do frequently when using agentic tools.

So I built agent-cli dev.

2. Why parallel development matters for agentic coding #

In my previous post on agentic coding, I described my workflow of running 5-6 Claude Code sessions simultaneously, each working on a different feature. This is how I can easily work on multiple features in parallel while waiting for an agent to process and generate code.

The usual way: Start feature A → wait for Claude to finish → review → move to feature B → repeat.

The better way: Start feature A in tab 1 → switch to tab 2, start feature B while A is working → switch to tab 3, start feature C → circle back to tab 1, review what Claude did → give feedback, move to next tab → repeat every 10-15 minutes.

This parallel approach allows me to go much faster. But it only works if each tab has its own completely isolated and working environment.

That’s where git worktrees come in. A worktree gives you a separate working directory for a branch, sharing the same git history but with independent file states.

The problem is the setup. Every time you want to start a new feature:

# The manual way (don't do this)
git fetch origin
git worktree add ../my-project-worktrees/cool-feature -b cool-feature origin/main
cd ../my-project-worktrees/cool-feature
uv sync --all-extras # or npm install, or poetry install, or...
cp ../.env .env
# Now open a new terminal tab...
# Navigate there...
# Finally start claude

After the 100th(?) time doing this manually, I knew I needed to automate it.

3. One command to rule them all #

Here’s what I built:

agent-cli dev new --agent

That’s it. One command. Here’s what it looks like:

→ Generated branch name: cool-crane
→ Creating worktree for branch 'cool-crane'...
→ Running: git fetch origin
→ Running: git worktree add -b cool-crane ~/Work/project-worktrees/cool-crane origin/main
✓ Created worktree at ~/Work/project-worktrees/cool-crane
✓ Copied env file(s): .env.example, .envrc
→ Detected Python project with uv
→ Running: uv sync --all-extras
→ Running: direnv allow
✓ direnv: allowed existing .envrc
✓ Started claude in new iterm2 tab

╭─────────────────────────────────────────────── Success ───────────────────────────────────────────────╮
│ Dev environment created: ~/Work/project-worktrees/cool-crane │
│ Branch: cool-crane │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────╯

4 seconds later, I have a new terminal tab with Claude Code already running in a fresh, isolated environment. Ready to work on my next feature.

What happens under the hood:

Generates a random branch name like clever-fox (you can just set the name yourself of course)
Creates the git worktree in a sibling directory
Detects the project type and runs the appropriate setup (uv sync, npm install, etc.)
Copies .env files from the main repo
Sets up direnv so the environment activates automatically
Opens a new terminal tab (works with tmux, zellij, iTerm2, and more)
Launches your coding agent in that tab

The Docker-style random names (clever-fox, happy-bear, swift-owl) there just for those too lazy to pick a name. Just agent-cli dev new --agent and start coding.

4. It knows your stack #

The command auto-detects your project type:

If it sees…	It runs…
`uv.lock`	`uv sync --all-extras`
`pixi.lock`	`pixi install`
`poetry.lock`	`poetry install`
`requirements.yaml`	`unidep install -e .`
`package-lock.json`	`npm install`
`Cargo.toml`	`cargo build`
`go.mod`	`go mod download`

For my projects using unidep, it even detects monorepos and adjusts the command accordingly.

It also generates the right .envrc for direnv. For a Python project with uv, that’s source .venv/bin/activate. For a conda/unidep project, it’s the full micromamba activation. For Nix projects, it’s use flake.

This means when you cd into the worktree later, your environment is automatically activated. No more source .venv/bin/activate.

5. Terminal magic #

The real magic is opening a new terminal tab with the agent already running.

The command detects which terminal you’re in and uses the appropriate API—whether that’s iTerm2, Kitty, Warp, or GNOME Terminal. It even works with terminal multiplexers like tmux and zellij (my current favorite), opening a new window/tab in your existing session.

6. Spawning agents with prompts #

The --prompt option transforms how I spawn parallel agents. Instead of just opening a blank Claude session, I can give the new agent its task immediately:

agent-cli dev new fix-auth-bug --agent --prompt "Fix the login validation bug in auth.py. The issue is that empty passwords pass validation."

The agent opens with the prompt already loaded and starts working immediately. No copy-pasting, no context switching, no “let me explain what I need you to do.”

For longer, more detailed prompts (which you should use for complex tasks), there’s --prompt-file:

agent-cli dev new new-feature --agent --prompt-file .claude/spawn-prompt.md

This is particularly powerful when you’re in a Claude session and discover a feature that needs work but is unrelated to your current task. Instead of context-switching or noting it for later, you can spawn a new agent right there:

Write a detailed prompt to a file (Claude can do this)
Run agent-cli dev new unrelated-feature --agent --prompt-file .claude/spawn-prompt.md
A new terminal tab opens with a fresh Claude session already working on the task
Continue with your original work

The spawned agent works independently in its own branch while you stay focused.

7. Teaching Claude to spawn agents #

Here’s where it gets really interesting: you can teach Claude Code itself how to spawn parallel agents.

agent-cli dev install-skill

This installs a Claude Code skill that teaches Claude how to use agent-cli dev. The skill includes detailed examples and prompt templates following Anthropic’s prompt engineering guide.

With the skill installed, you can say things like:

“Work on auth, payments, and notifications in parallel”
“This feature is unrelated to what we’re doing—spawn a new agent for it”
“Split this refactoring by module and work on them simultaneously”

Claude will write well-structured prompts (using proper XML tags, clear context, explicit requirements) and spawn the agents for you. Each spawned agent writes a report to .claude/REPORT.md when done, so you can easily review what happened.

One of my favorite patterns: I ask Claude to look at the latest 10 open GitHub issues and spawn an agent for each one. Ten independent parallel environments, set up in seconds, each working on a different issue. That’s the kind of leverage this enables.

8. My actual workflow #

Here’s how I use this in practice. I’m working on agent-cli itself, and I want to add three features:

# Tab 1: New RAG feature
agent-cli dev new rag-improvements --agent --prompt "Improve RAG chunking strategy for better retrieval accuracy"

# Tab 2: Fix a bug in the transcribe command
agent-cli dev new fix-transcribe-vad --agent --prompt "Fix VAD detection cutting off words at sentence boundaries"

# Tab 3: Refactor the config system
agent-cli dev new config-refactor --agent --prompt "Refactor config.py to use a single Config class with lazy loading"

Three commands, three isolated environments, three Claude Code sessions already working on their tasks.

I cycle through the tabs every 10-15 minutes:

Review what Claude did
Give voice feedback using my transcription workflow
Move to the next tab

When a feature is done, I have Claude open a PR from that branch. When the PR is merged:

agent-cli dev clean --merged

This uses the GitHub CLI to check which branches have merged PRs, then removes those worktrees and deletes the branches. No more zombie worktrees cluttering my disk.

9. Managing environments #

A few other commands I use regularly:

# List all worktrees
agent-cli dev list

# Navigate to a worktree
cd "$(agent-cli dev path clever-fox)"

# Remove a worktree
agent-cli dev rm clever-fox

# Force removal + delete branch
agent-cli dev rm clever-fox --force --delete-branch

# Check what's available on your system
agent-cli dev doctor

The doctor command is handy for seeing which terminals, editors, and coding agents are installed and detected.

10. Getting started #

agent-cli dev is part of the agent-cli package:

# With uv (recommended)
uv tool install agent-cli

Then in any git repository:

# Check what's available
agent-cli dev doctor

# Create your first parallel environment with a task
agent-cli dev new my-feature --agent --prompt "Add user profile page with avatar upload"

# Or install the skill so Claude can spawn agents for you
agent-cli dev install-skill

Supported coding agents: Claude Code, Codex, Gemini, Aider, GitHub Copilot, Continue, OpenCode, and Cursor Agent. Use --with-agent gemini to pick a specific one, or set a default in your config.

Supported terminals: tmux, zellij, iTerm2, Terminal.app, Kitty, Warp, and GNOME Terminal.

Supported editors: Cursor, VS Code, Zed, PyCharm (and other JetBrains IDEs), Neovim, Vim, Emacs, Sublime Text, and nano.

Conclusion #

The barrier between “I want to work on this feature” and “I’m actually working on it in an isolated environment” should be zero.

Before:

2-5 minutes of manual setup per feature
Often skipped because “it’s not worth it for a small change”
Mental overhead remembering all the steps

After:

One command, few seconds
No excuse not to work in isolation
More parallel features, faster iteration

If you’re using agentic coding tools and not yet working in parallel, you’re leaving productivity on the table. And if the setup friction was stopping you—well, now it’s gone.

Try it out and let me know what you think! The code is open-source at github.com/basnijholt/agent-cli.

Links #

Discovering Git worktrees: a handy tool for multitasking 📚

Thu, 19 Sep 2024 00:00:00 +0000

Recently, I discovered a game-changer in Git that has streamlined my workflow: worktrees. This feature allows developers to handle multiple branches of a single repository simultaneously, eliminating the need for constant branch-switching or multiple clones. For example, I typically want to keep the main branch in one editor window and the feature branch in another to easily test changes. With Git worktrees, I essentially have two separate working directories for each branch, making it easier to manage changes and switch between tasks.

What is a Git Worktree?

A Git worktree provides additional working directories linked to the same repository. This means you can easily work on different branches in parallel without duplicating repositories, saving both space and effort.

Benefits of Git Worktrees

Parallel Development: Effortlessly switch between branches for urgent bug fixes or new feature developments.
Efficiency: It’s lightweight, sharing the Git directory, and integrates smoothly with existing workflows.

Quick Commands

Create a Worktree:
git worktree add <path-to-new-worktree> <branch-name>
List Worktrees:
git worktree list
Remove a Worktree:
git worktree remove <path-to-worktree>

Conclusion

Incorporating Git worktrees into your workflow enhances productivity and organization. Whether dealing with bug fixes or new features, worktrees help maintain a cleaner environment.

ipynb_git_filters

Mon, 25 Nov 2019 00:00:00 +0000