For the past decade, most of my development workflow has lived in the terminal. Editors, shells, Git, long-running processes, logs, deploy scripts: they all fit naturally there.

With the rise of AI coding agents like Claude Code, OpenCode, and similar tools, the terminal has become even more important. These agents already work through the same primitives developers use every day: files, shell commands, Git branches, tests, package managers, and running processes.

But agentic development also changed how I think about my workspace.

I no longer work on only one branch at a time. I might have one branch where an agent is implementing a feature, another branch open for review, and main available for quick fixes or reference. Constantly switching branches in one checkout starts to feel clumsy. You end up stashing changes, reinstalling dependencies, restarting processes, and losing context.

That made me revisit a Git feature I had mostly ignored for years: worktrees.

Why Worktrees Started to Make Sense

Git worktrees let you check out multiple branches of the same repository at the same time. Instead of one repository directory constantly changing branches, each branch gets its own directory.

For example, you can keep your main repository clean:

~/Projects/my-app

and create separate directories for feature branches:

~/Projects/my-app-login-refactor
~/Projects/my-app-payment-fix
~/Projects/my-app-review

Each directory is connected to the same Git repository, but each can have a different branch checked out.

That is useful in a normal workflow, but it becomes much more useful with AI agents. An agent can work in one worktree, I can review code in another, and my main checkout can stay on main. There is no need to stash half-finished work just to inspect another branch.

The workflow becomes more parallel:

  • main stays clean and available
  • feature work happens in isolated directories
  • reviews can happen without interrupting current work
  • agents can run without taking over my main checkout
  • long-running dev servers can keep running per task

This fits the way I want to use AI tools: not as one big magical session, but as separate pieces of work that can be inspected, paused, resumed, or thrown away.

The Annoying Parts of Worktrees

Worktrees are useful, but they are not frictionless.

A new worktree often feels close to a fresh clone. The Git state is there, but the local development environment may not be.

Depending on the project, you may need to:

  • install dependencies
  • link or copy .env files
  • start a development server
  • open the right editor
  • start an AI agent in the correct directory
  • create a terminal or tmux session
  • remember which worktree belongs to which task

Those steps are small, but small steps matter when they happen every time. If creating a worktree feels like ceremony, I will avoid doing it and fall back to branch switching.

That is why I created wt, a small tool for automating the boring parts of my worktree workflow.

Introducing wt

The basic idea is simple:

wt ../foo

This creates a new worktree named foo and sets up a matching terminal environment for it.

For my workflow, that means wt can:

  • create the Git worktree
  • create a tmux session named after the worktree
  • link shared files like .env
  • install dependencies, such as running npm install
  • open Neovim in the new worktree
  • start an AI coding agent like OpenCode

The goal is not to hide Git. The goal is to remove the repetitive setup around Git so that using worktrees becomes cheap enough to do all the time.

If I want to try an idea, I can create a worktree. If I want an agent to work on a task, I can give it a separate directory. If I want to review a branch, I do not need to disturb anything else.

Why Tmux Fits So Well

Tmux has been part of my daily workflow for a long time, but worktrees made me appreciate it even more.

A worktree gives each task its own directory. Tmux gives each task its own terminal workspace.

That combination maps very naturally to development work. Each branch or task can have its own tmux session with its own editor, shell panes, logs, test watcher, dev server, and AI agent.

Instead of thinking:

Which branch am I on in this terminal?

I can think:

Which tmux session belongs to this task?

That is a much better mental model.

A typical session might have:

  • Neovim in one pane
  • a dev server in another
  • test output in another
  • an AI agent running in another

Because the session is tied to the worktree, I can leave it running, detach, switch to another task, and come back later without reconstructing the whole environment.

The Workflow

A simplified version of the workflow looks like this:

cd ~/Projects/my-app
wt ../login-refactor

That gives me a new worktree and a tmux session for the task. From there, an agent can start implementing the login refactor while I keep working elsewhere.

If I need to review another branch:

wt ../review-payment-fix

Now that review has its own directory and tmux session too. I can inspect it, run tests, make notes, or ask an agent to summarize the diff without touching the login refactor worktree.

Meanwhile, my main checkout remains clean:

~/Projects/my-app

That clean checkout is still useful. I can use it as a stable reference, pull the latest main, check production behavior, or create another worktree from a known good state.

Why This Matters More With AI Agents

Before AI agents, I usually had one main thread of development. I might switch branches occasionally, but most of my attention was on one task.

Agents make it easier to start parallel work. That is powerful, but it can also become messy. If every task shares one checkout and one terminal session, the workspace becomes difficult to reason about.

Worktrees add isolation. Tmux adds persistence. Together, they make agentic development feel less chaotic.

An agent can make changes in one worktree while I inspect another. If the agent goes in the wrong direction, I can delete that worktree without disturbing anything else. If the work is useful, I can review it like any other branch.

The important part is that each task has a boundary.

That boundary makes it easier to stay in control.

Closing Thoughts

Git worktrees used to feel like an interesting feature I did not quite need. AI coding agents changed that.

Once multiple branches can be active at the same time, worktrees stop being a niche Git trick and become a practical foundation for a terminal-based workflow. Combined with tmux, they give each task a separate, persistent workspace. Combined with a small helper like wt, the setup cost becomes low enough that I actually use them.

For me, this has made the terminal feel like a better IDE for agentic development: isolated workspaces, persistent sessions, fast switching, and no constant branch juggling.

The terminal was already where most of my development happened. Worktrees and tmux just made it fit the new workflow better.