Organizing 10+ Claude Code Projects Without Drowning in Terminal Windows

Claude Code is incredible for a single project. You open a terminal, start a session, and the AI helps you build, debug, and refactor at a pace that feels almost unfair.

Then you start using it on a second project. And a third. And before long, you’ve got a client dashboard, a personal side project, an open-source library, and three internal tools — all with active Claude Code sessions.

Your dock is a graveyard of Terminal.app windows. Your tmux has so many sessions you can’t remember which number maps to which project. You accidentally approve a file deletion in the wrong repo because you thought you were in a different tab.

The too-many-terminals problem is the tax you pay for Claude Code being good enough to use everywhere.

Why standard terminals can’t solve this

Terminals were designed decades ago for a world where you ran one or two tasks at a time. They give you tabs, maybe splits, and that’s it. There’s no concept of “this group of tabs belongs to this project” or “these sessions are related.”

When you’re running Claude Code across multiple projects, you need two layers of organization:

Project level: Which project is this session for?
Session level: What task is this particular agent working on within that project?

Terminal tabs give you a flat list. You get session-level separation but zero project-level grouping. So you end up with tab names like “bash - 1,” “bash - 2,” “bash - 3” and a mental map that falls apart the moment you step away for lunch.

Common workarounds (and their limits)

Rename your tabs. You end up with “client-api,” “client-tests,” “sideproject-main,” “oss-lib-refactor.” This helps until you have 12 tabs and the names get truncated. Still a flat list.

One terminal window per project. Now you have project-level grouping, but you’re switching between windows with Cmd+Tab alongside every other app. Not much better.

Tmux session-per-project. A tmux session for each project, with windows inside for individual tasks. This is the most organized traditional approach, but the overhead is real — creating sessions, naming windows, switching between them is all manual. And you still can’t see at a glance which sessions need attention across all your projects.

A better organizational model

The solution isn’t a better terminal — it’s a different organizational model. You need two things:

1. Group sessions by project

Every Claude Code session should belong to a project. When you switch to a project, you see only its sessions. When you’re done with a project for the day, you collapse it and it’s out of your way.

You need a persistent element — always visible, regardless of what you’re focused on — that shows you all your projects and their sessions. Not buried in a menu. Not in another app. Right there, at the edge of your screen.

How Crystl implements this model

This is exactly why Crystl uses the gems and shards metaphor.

A gem is a project. It maps to a directory on your machine — your repo root, your monorepo package, whatever makes sense. Each gem gets a unique color, so there’s an instant visual signal for which project you’re looking at.

A shard is a Claude Code session within a gem. Your “client-dashboard” gem might have three shards: one refactoring the API layer, one writing integration tests, and one updating the docs. They’re grouped under the gem, not mixed into a flat tab bar.

The Crystal Rail is the persistent navigation piece. It’s a glass bar anchored to the edge of your screen that shows all your gems and their shards. You always know what’s running, what’s waiting, and what’s finished — across every project, without clicking into anything.

Scaling to 10+ projects

This model scales where tabs don’t. With 10 projects and 2-3 sessions each, you’d have 20-30 terminal tabs in a flat list. In Crystl, you have 10 gems in the Crystal Rail, each expandable to show its shards. The hierarchy does the organizational work for you.

You can also set up each gem with its own MCP server configuration and API keys, so when you switch between projects, the right tools and credentials follow automatically. No more “wait, which API key is this session using?”

Parallel work across projects

When you need to run agents simultaneously across different projects, isolated shards keep everything clean. Each agent works in its own git worktree, so agents in different shards can’t step on each other — even within the same repo.

Combine this with notifications, and you can kick off work across five projects, focus on one, and get pinged when any of the others need your attention.

Practical tips for multi-project Claude Code workflows

Name everything. “Refactor auth middleware” beats “bash - 7.”

Close finished sessions. Old sessions add noise. If you need the conversation later, Crystl keeps your conversation history so you can always go back.

Batch similar work. Spend an hour on the client project, then switch to the side project. Context-switching between projects is expensive even when the AI is doing the coding.

Use formations for repeatable setups. If you always start a project with the same sessions, save that layout. Crystl calls these formations — launch your whole workspace with one click.

Terminal chaos adds up

Disorganized terminals aren’t just annoying — they’re a productivity leak. Every time you hunt for the right tab, re-orient yourself in a session, or accidentally interact with the wrong agent, you’re burning minutes and focus.

Claude Code makes you faster at building. The terminal you run it in shouldn’t slow you back down.

Try Crystl free at crystl.dev/login.