AI terminal sprawl: taming multi-repo coding CLI chaos

You open Claude Code in the API repo. Codex in the frontend. A plain shell for the infra scripts. Then you need a second Claude Code session because you're testing an integration that touches both services. Another shell for logs. Codex again because the frontend build broke.

Twelve tabs. Three repos. One brain trying to remember which tab belongs to where.

This is AI terminal sprawl, and it's the untalked-about cost of agent-assisted development. The tools got better. The workspace management didn't.

The sprawl pattern

Traditional terminal sprawl — too many tabs, no naming discipline — is manageable. You learn tmux, you name your sessions, you move on.

AI coding sprawl is different because each tool claims its own terminal. Claude Code needs a persistent session. Codex wants its sandbox. Your manual debugging still happens in plain zsh. Multiply by the number of repos you touch in a day, and the tab count doubles or triples.

The symptoms:

• Wrong-repo commands. You type git push in the infra terminal thinking you're in the API repo. Nothing explodes, but the wrong branch goes to the wrong remote.
• Lost session state. You asked Claude Code to investigate a bug twenty minutes ago. Which tab was that? You open a new one and re-explain the context.
• Invisible active work. Three AI sessions are running. One finished five minutes ago. One is stuck in a loop. One is waiting for your input. You don't know which is which without clicking through all of them.
• Context bleed. You paste a stack trace into the wrong agent session. It starts "fixing" code in a repo it shouldn't touch.

Why tmux alone doesn't fix it

Tmux solves the naming and layout problem. It doesn't solve the identity problem.

A tmux session named api tells you which repo it's for. It doesn't tell you whether the Claude Code session inside it is still active, what it's working on, or whether it's the session you started this morning or a fresh one.

The gap is between terminal organization and session awareness. Tmux organizes terminals. What you need is something that organizes work lanes — repo plus tool plus task, as a single unit you can see at a glance.

Practical approaches that work today

1. One tmux session per repo, strict naming

Create tmux sessions named after the repo, not the tool:

tmux new-session -s content-api
tmux new-session -s frontend
tmux new-session -s infra

Inside each session, use windows for different tools:

# Inside the content-api session
tmux new-window -n claude    # Claude Code lives here
tmux new-window -n shell     # Manual commands here
tmux new-window -n logs      # Tailing logs here

The discipline: never run a coding CLI outside its designated session. If you need Claude Code for the frontend, switch to the frontend session. Period.

2. Direnv for automatic context

Pair tmux with direnv so that every shell in a repo directory automatically loads the right environment:

# content-api/.envrc
export PROJECT_NAME="content-api"
export CLAUDE_PROJECT="content-api"
layout node

This prevents the wrong-repo problem at the environment level. Even if you accidentally cd into the wrong directory, direnv will swap your env vars to match.

3. Session status in your prompt

Add the current tmux session name and window name to your shell prompt:

# In .zshrc
if [ -n "$TMUX" ]; then
  TMUX_SESSION=$(tmux display-message -p '#S')
  TMUX_WINDOW=$(tmux display-message -p '#W')
  PS1="[$TMUX_SESSION/$TMUX_WINDOW] $PS1"
fi

Now every command you type shows [content-api/claude] or [frontend/shell] before the prompt. Wrong-repo commands become obvious before you hit enter.

4. Kill idle sessions aggressively

AI coding sessions accumulate. You start one, context-switch, forget about it, start another. Set a rule: if a coding CLI session has been idle for more than thirty minutes, kill it and start fresh when you need it.

# List sessions with last activity time
tmux list-sessions -F '#{session_name}: #{session_activity}'

The context you lose by killing a stale session is almost always less than the context you lose by having six sessions and not knowing which one has the work you need.

5. A session inventory command

Write a small script that shows all active coding CLI sessions across all repos:

#!/bin/bash
echo "=== Active coding sessions ==="
for session in $(tmux list-sessions -F '#{session_name}'); do
  for window in $(tmux list-windows -t "$session" -F '#{window_name}'); do
    pane_cmd=$(tmux list-panes -t "$session:$window" -F '#{pane_current_command}' | head -1)
    echo "  $session/$window -> $pane_cmd"
  done
done

Run it before starting new work. If you already have a Claude Code session in the content-api repo, go use that one instead of opening a new one.

The deeper problem

Terminal sprawl is a symptom. The root cause is that AI coding tools don't have a concept of a "project lane" — a persistent, named workspace that survives across sessions and shows its status without you opening it.

IDE-based tools like Cursor handle this by being the IDE. Everything lives in one window. But if you work across multiple repos, you're back to multiple windows, and the sprawl returns at the IDE level instead of the terminal level.

The tools that will win this space are the ones that treat multi-project, multi-agent orchestration as a first-class problem — not as "open more tabs." Until then, the tmux-plus-direnv-plus-discipline stack is the best we've got.

The takeaway

AI terminal sprawl isn't a tooling problem you can ignore. Every wrong-repo command, every re-explained context, every lost session is time you're paying for the privilege of using tools that were supposed to make you faster.

The fix isn't a new tool. It's a workspace contract: one session per repo, strict naming, automatic context, aggressive cleanup. Boring. Effective. The opposite of the sprawl.