Skip to main content
Claude Manager: Keeping Track of Claude Code Across Projects

March 23, 20265 min read

In my last post, Back to the Terminal, I wrote about why the terminal became a much bigger part of my workflow again.

That shift brought a new problem with it.

I was no longer using Claude Code in one repo at a time. I had sessions running across different projects, sometimes across different worktrees, all inside tmux.

That worked well enough at first. But after a while, it became harder to keep track of what was actually going on.

Which session was still running?
Which one was done?
Which one was waiting for me?
And which one was blocked on a confirmation prompt somewhere in another pane?

Notifications helped, but only up to a point. They told me that something happened, but nothing more. When you have multiple sessions going on, you need more than a ping. You need a better overview.

So I built a small tool for myself: claude-manager.

The Problem

Once Claude Code became part of my regular workflow, I stopped treating it like a one-off assistant and started treating it more like an active layer in my environment.

That means parallel work.

A feature in one repo.
A refactor in another.
A side experiment in a separate worktree.
Maybe something running remotely too.

At that point, the hard part is not starting a session. The hard part is staying aware of all of them.

I wanted to know:

  • what Claude Code sessions were currently active
  • where they were running
  • which project or worktree they belonged to
  • whether one of them was waiting for input
  • and, if it was waiting for confirmation, what exactly it needed

That last part mattered a lot.

Sometimes Claude is waiting on a confirmation that is obviously fine, and I just want to approve it quickly.

Sometimes it is asking for something that needs a closer look, and I do not want to confirm blindly.

I wanted an easy way to read what it needed first, then decide whether to confirm it or leave it for later.

Why Tmux

I looked at alternatives like cmux, but I did not want to switch setups again.

I am already happy with the terminal workflow I have, and tmux is a big part of it. So instead of moving to a different environment, I thought it made more sense to build something on top of the one I already use.

That was really the whole idea: keep the setup, remove some friction.

The Flow

The flow is simple.

I live in the manager now. From there, I can see which Claude session needs feedback, and decide from there.

If the request is straightforward, I can respond directly from the dashboard with 1, 2, or 3.

If it needs a closer look, I jump into the session with l, do what I need to do, and then return to the manager with leader+m.

If I want to quickly inspect the git state around that work, I can open lazygit directly from there with g.

And if I want to send a quick command, a simple follow-up I can just press p and send it without leaving the manager.

That is the part I like most.

The tool is not just about showing me sessions. It helps me move between overview, decision, and action without breaking the flow.

Why It Is Claude-Specific

Right now it targets Claude Code specifically because that is the tool I use.

Could this be abstracted later? Probably.

But I do not really care about making it generic just for the sake of it.

I built it to solve a concrete problem in my own setup, and I would rather have a tool that fits the workflow well than a broader abstraction that is less useful day to day.

What Changed for Me

The main improvement is not that it saves a few keystrokes.

It reduces mental overhead.

I do not have to remember as much. I do not have to manually check everywhere as often. And when Claude is waiting on something, I can understand the request faster before deciding what to do.

That makes it easier to run multiple threads of work in parallel without the whole setup feeling messy.

Which is really the point.

Once these tools become part of your normal workflow, the challenge shifts. It is no longer only about what the model can do. It is also about how well you can manage the environment around it.

Try It

If your setup looks anything like mine — terminal-heavy, tmux-based, multiple Claude Code sessions across repos or worktrees — you might find this useful too.

Repo: github.com/yhabib/claude-manager
Landing page: yhabib.github.io/claude-manager

If you try it, I’d love to hear what you think.

I share these kinds of workflow experiments on X, so feel free to reach out there.