Guide6 min read

Too many Claude Code sessions? How to manage multiple AI agent sessions without the friction

Managing many Claude Code or Codex sessions means tab sprawl, runs that die when the laptop sleeps, lost context and constant checking. Practical fixes (names, worktrees, tmux, notes, notifications) and the structural one: sessions as tasks on a calendar.

Written by

To manage many AI agent sessions without the friction, give every session a name, its own git worktree and a notes file, run them in tmux or on an always-on machine, and send every "needs input" moment to one notification channel. The structural fix is to treat sessions as scheduled tasks that run in the cloud and report back.

Why does running many Claude Code or Codex sessions get exhausting?

Each agent session is cheap to start and expensive to keep track of. Run six or seven at once, plus their dev servers and logs, and the friction looks like this:

  • A dozen terminal tabs with near-identical titles. Finding the billing session means clicking through them one by one.
  • Sessions die with the laptop. Close the lid for a meeting and every run stops.
  • Context is trapped in each session. You forget which one knows about yesterday's schema change, and starting fresh means explaining it again.
  • Constant checking. Any session might be sitting on a permission prompt, so you cycle through all of them to find out.
  • Re-authenticating. New machines, new containers and expired tokens mean logging in to the CLI, GitHub and every service again.
  • Usage limits mid-task. A long run hits your plan's limit and stops, and you notice an hour later.

The agents do their part of the job well enough. The overhead is you, acting as the router between them. The fixes below remove that overhead in stages, from quick habits to a different setup.

How do I keep track of which agent session is doing what?

Treat each session as one task with a name, and write its state somewhere outside the session.

  1. One task per session. A session that fixed a bug, then started on analytics, then answered a pricing question holds context nobody can reuse.
  2. Name it. Rename the terminal tab or tmux window after the task, for example billing-webhooks. Use the same name for the branch and the notes file.
  3. Keep a notes file per task. notes/billing-webhooks.md holds the goal, current status, decisions made and the next step. Before you step away, ask the agent to update it.
  4. Resume on purpose. In Claude Code, claude --continue reopens the most recent conversation in the current folder, and claude --resume lets you pick an older one. Codex can resume past sessions too.

The notes file does the heavy lifting. A transcript is long and only readable by scrolling. A ten-line status note tells you, or a fresh agent, everything needed to pick the task back up in a minute.

Should each AI agent session get its own git worktree?

Yes, for any session that edits code. Two sessions in the same checkout overwrite each other's changes, and one session's half-finished edit can break the other's test run.

A git worktree gives each session its own folder and branch, backed by one repository:

git worktree add ../app-billing-webhooks -b agent/billing-webhooks
cd ../app-billing-webhooks && claude

When the task merges, clean up with git worktree remove ../app-billing-webhooks, and run git worktree list to see what is still open.

Practical pitfalls:

  • Untracked files stay behind. A .env file and local config do not come with a new worktree, so copy them or script it.
  • Dependencies install per worktree. That costs disk space and time.
  • Ports collide. Give each worktree its own dev server port.
  • Shared local databases collide. Use a separate database or schema per session when migrations are involved.

Matching names across the worktree, branch, tmux window and notes file means one word finds everything about a task. For running a lead session over several of these, see Claude Code orchestration.

How do I keep agent sessions running when my laptop sleeps?

tmux keeps a session alive when you close the terminal window. Start each agent in a named tmux session, detach, and reattach later:

tmux new -s billing-webhooks
# start the agent, then press Ctrl-b d to detach
tmux ls
tmux attach -t billing-webhooks

That covers closed windows and crashed terminal apps. Sleep is a different story: when the laptop sleeps, every process on it pauses, tmux included. On a Mac, caffeinate -i stops idle sleep while a command runs, but closing the lid on battery still sleeps the machine.

The lasting fix is an always-on machine, such as a small cloud server or a desktop at home that you connect to from your laptop. Your sessions run in tmux on that machine, and the laptop becomes a window onto them.

The trade-off is that you now run a server. You install and update the CLIs, sign in again on that machine, keep its keys secure and pay for it. For many people it is worth it, and it is also the point where a hosted runner starts to make sense.

How do I stop checking every agent session for questions?

Make sessions tell you when they need you, and cut the number of things they need you for.

Get notified. Claude Code supports hooks: a Notification hook runs a command when Claude needs your permission or input, and a Stop hook runs when it finishes. Codex has a notify setting in its config that runs a program when a turn completes. Point both at one channel, such as a desktop notification, a phone push service or a Telegram bot, and put the session name in the message.

Ask less often. Most prompts are for safe actions. Allow the commands you always approve, such as running tests, linting and reading files, in the agent's permission settings, and keep prompts for pushing, deploying and anything that leaves your machine.

Write briefs that can finish. A session with a clear goal, done criteria and a named deliverable asks fewer questions. The guide to coordinating several agents covers how to route the remaining questions into a single queue.

With all three in place, you go to a session because it called you, and the rest of the time you leave it alone.

How do I avoid re-authenticating in every agent session?

Authentication friction grows with the number of places your agents run. Every new machine or container can mean another round of CLI login, gh auth login, API keys and service sign-ins, and every fresh worktree starts without your .env file.

Ways to cut it down:

  • Fewer machines. Run sessions on one always-on machine, so the CLI and GitHub logins happen once.
  • One secrets source. Keep API keys in one place, such as your password manager's CLI or a single env file outside every repo, and load them from there instead of copying .env files around.
  • Keep secrets out of prompts. Anything you type into a session lands in its transcript, which is stored and sent to the model.
  • Prefer stored connections. Where a service has an API or an MCP server, give the agent a stored credential instead of a browser login it has to repeat.
  • Expect expiry. Tokens and sessions expire. List in each task's notes which accounts it depends on, so a failed login is easy to trace.

The deeper fix is to attach credentials to the workspace instead of to each session, so a new agent inherits access without you signing in again.

What is the structural fix for too many agent sessions?

Manage tasks instead of sessions. A session is a process in a terminal. A task has a goal, an owner, a schedule and a deliverable, which is what you actually care about.

A terminal tab per agentA task on a calendar
Where it runsYour laptop, while it is awakeA cloud machine that keeps running
How you find itClick through tabsLook at today on the calendar
ContextInside one transcriptIn workspace files and task notes
When it needs youA prompt in some tabOne inbox, plus a phone message
Recurring workRe-run by hand or by cronA routine on a schedule
ResultsScroll the transcriptDeliverables attached to the task

Once work is organized this way, the number of agents matters much less. Ten tasks on a calendar take the same glance as two. You open the calendar to see what is happening, the inbox to answer what needs you, and a deliverable to review what finished.

Any setup that moves you toward the right-hand column helps, whether you build it yourself or use a product.

How does Kavela run agent sessions as tasks on a calendar?

Kavela is a cloud workspace where agent sessions become tasks. You tell Kav, the agent who runs your workspace, what you want. Kav files tasks and hands each to the right worker agent, and every task, routine and event lands on a calendar with month, week and day views.

  • Runs in the cloud. Each worker has its own cloud computer with a shell, files, git and a browser. Close your laptop and the run keeps going.
  • Your own plan. Choose "My Claude plan" or "My Codex plan" for an agent and sign in once from a card. Claude Code or Codex then runs in that cloud computer on your subscription. Connect more than one account and Kavela rotates when one hits its limit. When all are at their limit, the run pauses and asks you once: wait and resume, finish on Kavela credits, or cancel.
  • Connect once. Connections belong to the workspace, so every agent can use them. Sign-ins happen in a secure takeover where your password never passes through the model.
  • One inbox. Sign-ins, choices and deploys wait in one Approvals inbox. Everything else runs.
  • Telegram. Talk to Kav, answer approvals, check /tasks and get a regular digest.

Kavela is in early access. Start your free trial and bring the Claude or Codex plan you already pay for.

Keep reading