# banteg/agents is a workflow note, and its best advice is to stop feeding models repomix output

> A personal configuration write-up for running Codex and Claude Code: worktree wrappers so parallel agents stop colliding, macOS seatbelt sandboxing so auto-approval is survivable, a devcontainer for unattended runs, git archive instead of repomix for reviews, and a warning about the tool whose uninstall is a 730-line shell script.

**banteg/agents** — my workflows for ai agents like codex and claude

- Repository: https://github.com/banteg/agents
- Stars: 372 · Forks: 28
- Language: Python
- License: not declared
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/banteg-agents

## Four notes, one repository: worktrees, sandbox, context and notifications

This is a workflow document, not a library. The description says it plainly: my workflows for ai agents like codex and claude. The repository holds a .gitignore, a codex directory, a devcontainer directory and the readme itself, and the primary language is recorded as Python because of the scripts inside those directories rather than because there is an importable package.

So read it as a set of decisions someone made after using these tools, several of which contradict the advice you get elsewhere. The opening claim is the load-bearing one: agents do not like files changing under them as they carry out their plans, and isolating them in separate directories stops them touching each other's changes.

The stated cycle follows from that. Create a worktree, make some commits, then either discard it or open a pull request. For the pull request the note says to use gh pr create or just ask claude. Once merged, discard the worktree and prune the branch.

Everything after that is a specific technique inside that cycle: worktree wrappers, sandbox settings, devcontainers, a better way to hand a model a repository, and notifications. Two sections are warnings rather than recommendations, and one of them is the most useful thing in the document.

## Absolute worktree paths break in a devcontainer, and git 2.48 added the fix

There is a bug hiding in the interaction between two otherwise unrelated sections, and this is the one that costs people an afternoon.

By default git stores absolute paths in worktree metadata. That is fine on a laptop and wrong inside a devcontainer, because the container sees a different path for the same directory. The note identifies the consequence directly: this breaks if you use devcontainer.

Git 2.48 and newer added relative path support, and one config line enables it.

```bash
git config --global worktree.useRelativePaths true
```

Two details follow from how that setting behaves. It is global, so new worktrees in all repositories use relative paths rather than just the one you are standing in. And it is forward-looking only: to migrate worktrees that already exist you run a separate command.

```bash
git worktree repair
```

That second line is the one people miss. Turn the setting on, create one worktree, see a relative path in the metadata, and conclude that everything is fixed, while every worktree created before the change still points at absolute paths and still breaks the moment a devcontainer moves it.

So the order matters: set the flag, then repair, then create worktrees.

## git-wt covers four commands, worktrunk covers the whole cycle

The note's position is that git worktree exists but its user experience is not great, and it recommends two wrappers rather than one.

git-wt is the small one. It installs with brew.

```bash
brew install k1LoW/tap/git-wt
```

Its configuration is one key plus a gitignore entry: put worktrees under .worktrees inside the repository, add that to ~/.gitignore_global, then point the tool at the directory.

```bash
git config wt.basedir .worktrees
```

What you get is four commands. git wt with no argument lists every worktree. git wt with a branch name switches to it and creates the branch if it does not exist. git wt -d does a soft delete of both worktree and branch, and git wt -D does the hard version.

worktrunk is the heavier option, and the reason given is that it closely matches the create, pull request, merge, cleanup cycle, with extras such as auto-running install scripts in the fresh worktree or generating commits with the llm command line tool. Its config file holds a path template.

```toml
worktree-path = ".worktrees/{{ branch }}"
```

The command list is where the difference shows. wt switch -c -x codex feat/branch switches to a worktree and launches codex in it, so the agent starts inside its own directory. wt merge squashes, rebases, merges into master and removes both the worktree and the branch in one step. wt step commit writes a commit based on the diff and the style of the previous commit. wt remove cleans up and prunes. wt select is an interactive switcher listing every worktree with its diff against master.

## Seatbelt sandboxing is what makes auto-approval defensible on macOS

The complaint is specific: you keep getting permission prompts in Claude Code, and you want it to behave more like Codex. The answer given is macOS seatbelt sandboxing, enabled through the Claude settings file.

```json
{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true
  }
}
```

The mechanism is the reason this is on the page. Bash commands run inside macOS's seatbelt sandbox, which restricts file writes to the project directory and limits network access. Auto-approval then applies only to commands running inside that sandbox, so the prompts disappear without the protection disappearing.

That ordering is the point. Turning on auto-approval alone is a much larger decision than turning on a sandbox and then allowing anything the sandbox permits, because the second setting has a well-defined blast radius: this project directory, and less network than you had.

The limitation is the platform. Seatbelt is a macOS mechanism, so this particular note does nothing for a Linux or Windows machine, and the next section is the answer for those, or for anyone who wants isolation regardless of host.

## For unattended runs, the devcontainer is the isolation and the shell is tmux

Running agents unattended, in what the note calls yolo mode, is best done in a devcontainer. Two reasons are given: it provides isolation, and it lets you skip permission prompts. The requirement is Docker, with orbstack named as a preferred drop-in replacement.

The install is a script in the repository.

```sh
./devcontainer/install.sh self-install
devc /path/to/repo
```

The comment next to the second line says what you get: you are in tmux with claude and codex. That is the part that makes the difference for an unattended agent, because a container that exits when a session dies is not much use for a long-running task. tmux is what lets the work survive, and the wrapper is what gets you into it.

Read this section together with the relative-worktree section and the whole picture resolves. Worktrees give each agent its own directory, the container gives each run its own filesystem and network position, and seatbelt or prompt skipping handles the macOS case where you are not in a container at all.

The deeper documentation is in devcontainer/readme.md, which this repository's readme points to rather than duplicating.

## git archive replaces repomix, and a bundle carries the history with it

This is the section that argues with common practice, and the claim is blunt: most people reach for repomix or code2prompt and feed the model a giant XML or markdown file, and that is outdated practice.

The recommended alternative is a zip made directly by git.

```sh
git archive HEAD -o code.zip
# if you need only part of the repo:
git archive HEAD:src -o src.zip
```

Why this is better is not spelled out, but the properties are visible in the commands: the archive contains exactly the tracked tree at a commit rather than a lossy summary of it, and the second form scopes the archive to a subtree when the whole repository is too much context to send.

The documented compatibility is broad: it works with GPT Pro, Claude and Gemini.

And when history matters, there is a second format.

```sh
git bundle create repo.bundle --all
```

A bundle carries commit messages, prior attempts and regressions with it, and the note says GPT and Claude can both understand one. That is the difference between giving a model a snapshot and giving it a trajectory, which is what you want when the question is why something regressed rather than what the code looks like now.

The intended use cases are named: architecture, refactors, debugging, and tell me what to fix next reviews.

## takopi bridges four agent CLIs, and beads needs a 730-line uninstall script

Two closing notes, one a recommendation and one a warning.

For full Telegram control of agents, the recommendation is takopi. It bridges codex, claude code, opencode and pi, streams progress, and supports resumable sessions, so a task started on your phone can be picked up in the terminal later. Installation is a uv tool install, then you run it in your repository.

```bash
uv tool install takopi
```

Resumable sessions are the part that changes how you work rather than how you are notified: a long task is no longer bound to the machine that started it.

For simple completion notifications, there is a codex notify script, documented at codex/notify_telegram/readme.md, that sends a Telegram message at the end of each turn. That is the lighter option when you do not want a bridge holding a session open.

The warning is about beads, which the note says is often recommended, and whose removal requires a 730-line shell script because it installs hooks in places you did not know existed.

That sentence is the most valuable thing in the document for anyone installing agent tooling. A tool that writes hooks into your editor, your shell and your version control hooks has changed your machine, and a tool with that reach needs a correspondingly clear exit path before you install it, not after.

Nothing here is packaged. There is no licence file at the root, no releases, and the last push was on 2026-05-25, so treat it as one person's current practice rather than maintained guidance.

## Conclusion

Adopt the parts of this that are configuration rather than opinion: relative worktree paths, the seatbelt sandbox settings, and handing a model a zip made by git instead of a repomix dump, because all three are commands you can apply today and measure. Be sceptical of the wrapper choice, since git-wt and worktrunk overlap heavily and picking one is a habit rather than a decision. Verify three things first: that your git is 2.48 or newer before you enable relative worktree paths, and that you run git worktree repair on existing worktrees rather than assuming new ones are covered, that the seatbelt settings only apply on macOS, and what the agent hooks in your own environment already do before you install another tracker. The repository has no licence file and no releases, and the last push was on 2026-05-25.

## FAQ

### What is in the banteg/agents repository?

It is a workflow note rather than a library: git worktree isolation for parallel agents with git-wt and worktrunk wrappers, macOS seatbelt sandbox settings for Claude Code, a devcontainer script for unattended runs, git archive and git bundle instead of repomix for code reviews, and Telegram notifications through takopi.

### How do I stop git worktrees from breaking inside a devcontainer?

Git stores absolute paths in worktree metadata by default, which breaks when a devcontainer sees a different path. Git 2.48 and newer support relative paths: run git config --global worktree.useRelativePaths true, then migrate existing worktrees with git worktree repair.

### How do I let Claude Code run bash commands without permission prompts on macOS?

Enable the sandbox in ~/.claude/settings.json with sandbox.enabled true and sandbox.autoAllowBashIfSandboxed true. Seatbelt then restricts file writes to the project directory and limits network access, and auto-approval applies only inside that boundary.

### What does the note say about giving an AI model a repository to review?

It calls repomix and code2prompt output outdated practice and recommends a zip produced by git instead, for example git archive HEAD -o code.zip, or git archive HEAD:src -o src.zip for one subtree. For commit history, prior attempts and regressions, it suggests git bundle create repo.bundle --all.

## Sources

- [banteg/agents on GitHub](https://github.com/banteg/agents)
- [Issues](https://github.com/banteg/agents/issues)
- [README](https://github.com/banteg/agents/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/banteg-agents