How to manage multiple Claude Code and Codex sessions

To manage several Claude Code and Codex sessions at once, name every session after its task, have each one notify you when it is waiting, and send all their questions to a single queue that you answer in order. Then limit how many you start to how many you can review, because your attention runs out long before the agents do.

The tools here are the ones that ship with Claude Code and git. Commands were checked against Claude Code 2.1.296 and codex-cli 0.159.0 in October 2026.

What actually goes wrong with many sessions?

Starting four agents is easy. The trouble comes twenty minutes later:

• One has been waiting on a permission prompt since minute two, in a terminal tab you have not looked at.
• One finished and you cannot remember which tab, or what you asked it.
• Two have questions, and answering either means reloading that task into your head.

The scarce thing is you. Every idle agent is waiting on a person, and every switch between tasks costs that person a few minutes of context. Managing sessions well means cutting the time an agent waits for you and the number of times you switch.

Name every session after its task

Claude Code lets you name a session when you start it, and resume it by that name later:

claude -n fix-login-redirect
claude --resume fix-login-redirect

Inside a session, /rename fix-login-redirect does the same and shows the name on the prompt bar. The name also appears in the terminal title, which is what you see when scanning tabs.

Use one name for everything that belongs to the task: the session, the branch, the worktree folder. claude --worktree fix-login-redirect -n fix-login-redirect gives you a session and an isolated checkout that match. If worktrees are new to you, start with Git worktrees for AI coding agents.

Get told when an agent is waiting

Claude Code fires a Notification hook when it is waiting for input or permission. Add this to ~/.claude/settings.json on a Mac (the hooks guide has the Linux and Windows versions):

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude Code needs your attention\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

Two things to know. If nothing appears, run osascript -e 'display notification "test"' in Terminal once; the notification goes through Script Editor, which needs notification permission in System Settings. And the timing is deliberate: per the hooks reference, the permission notification fires after the prompt has waited about six seconds, and the idle one about a minute after Claude finished responding.

Keep one queue for questions

A notification says something needs you. With five sessions you also need to know which one, and what it wants, without opening five tabs. There are two ways to get there by hand.

Agent view, for Claude Code sessions. claude agents opens one screen listing your background sessions, grouped so the ones that need input sit above the ones still working. You start a background session with claude --bg "investigate the flaky checkout test", and reach one with claude attach <id>, claude logs <id> or claude stop <id>. Anthropic labels agent view a research preview, so expect it to change.

A plain file, for everything. The hook receives JSON on standard input with the notification type, the message and the session's working directory. Append it to one file and you have a queue covering every Claude Code session on the machine:

#!/bin/sh
# ~/.claude/hooks/queue.sh: one line per "needs you" event
jq -r '[.notification_type, .cwd, .message] | @tsv' >> "$HOME/agent-questions.tsv"

Make it executable, point the hook's command at it, and keep tail -f ~/agent-questions.tsv open in a small pane. Because each session runs in a worktree named after its task, the directory column tells you which task is asking.

Codex sessions will not write to that file by themselves. For those I use the low-tech version: one tmux window per session, each named after its task, and a habit of walking the windows left to right. It is cruder than a queue and it still beats unnamed tabs.

Whichever you use, answer in order and finish each answer. Read the question, look at what the agent needs, reply, move on. Jumping to whichever session flashed most recently is how one task ends up waiting an hour.

Cut the number of questions

Each question you prevent is a switch you do not make.

• Allow the routine commands up front. Put your test, lint and build commands in permissions.allow in the repo's .claude/settings.json, and deny the ones that should never run, such as Bash(git push *). Deny rules apply in every permission mode.
• Write the prompt so there is nothing to ask. Name the files, the expected behaviour, and what done looks like. "Fix the login bug" produces three questions. A paragraph with the symptom, the location and the test to add produces none.
• Tell the agent what to do when stuck. "If you cannot make the test pass in three attempts, stop and write what you tried." A clear stop is cheaper than a question at the wrong moment.

When does running more sessions stop paying?

Earlier than it feels like it should. Simon Willison, who has written the most useful account of working this way, says he "can only focus on reviewing and landing one significant change at a time". What he finds worth running alongside that are tasks with low review cost: research for a proof of concept, questions about how existing code works, small maintenance jobs, and carefully specified work.

That matches my experience. The signs that I have started too many:

• Unreviewed branches pile up. git branch --no-merged main | wc -l goes up every day. Each of those is work that will conflict with the next one.
• Finished sessions sit for hours. If results wait longer than they took to produce, another agent adds nothing.
• Two sessions touch the same files. Worktrees stop them overwriting each other. They do not stop the merge conflict.
• The limit runs out midweek. Claude and Claude Code draw on the same usage limit, and every session counts against it. See How to make your Claude Code weekly limit last.

My working rule is to count reviews. If I can review and merge four results today, I start four tasks, and the ones that do not need me at a desk go into the evening queue, as described in How to run Claude Code overnight, safely.

Where Vakr fits

The plain-file queue works for one agent on one machine and gets awkward past that. Vakr is the Mac app I built for the rest: a single list called Needs you that holds every question, permission prompt, failure and finished review from Claude Code, Codex and other agents, across the Machines you have paired. You answer with a keystroke, or from your phone. It also shows each Project's share of your weekly limit. Vakr is in early access with a waitlist, and it runs on the subscriptions you already have.

Questions

How many Claude Code sessions can I run at once?

As many as your machine and usage limit allow, which is more than you can use. The practical limit is review: I start no more tasks in a day than I can review and merge that day.

How do I know which session needs me?

Add a Notification hook so you are told when one is waiting, and name sessions after their tasks so the notification means something. For Claude Code background sessions, claude agents groups the ones that need input at the top.

Can two sessions work in the same repo at the same time?

Yes, if each has its own git worktree, so they edit separate checkouts on separate branches. In one directory they will trip over each other's unfinished edits.

Do Claude Code and Codex sessions share a usage limit?

No, they are separate subscriptions from different vendors. Sessions of the same tool do share: all your Claude Code sessions, and your use of the Claude apps, count against the same limits.

How Vakr compares with other tools for running agents: One, Orca, T3 Code, Agentbox and Conductor.