Claude Code runs in one directory at a time. It indexes the codebase it’s in, understands that project’s structure, and makes changes within that scope. If you’re working on two or three projects simultaneously — an API, a frontend, a shared library — you need separate Claude Code sessions for each.

Here’s how to set that up efficiently.

The multi-project challenge

When you run Claude Code in a single terminal, switching between projects means:

Exit Claude Code (or open a new terminal)
cd to the other project
Launch Claude Code again
Wait for it to index the new codebase
Start prompting

Every project switch costs 30-60 seconds of setup time plus a complete mental context switch. And you can’t see what the first project’s agent is doing while you work on the second.

The grid solution

In GridTerm, open a grid and dedicate terminals to different projects:

Two projects (2x2 grid)

	Left	Right
Top	API: `claude`	Frontend: `claude`
Bottom	API: `npm run dev`	Frontend: `npm run dev`

Both agents run simultaneously. Prompt the API agent, switch to the frontend agent, prompt that one. Both dev servers are visible so you can verify changes in real time.

Three projects (3x3 grid)

	Col 1	Col 2	Col 3
Row 1	API: `claude`	Frontend: `claude`	Shared lib: `claude`
Row 2	API: dev server	Frontend: dev server	`npm test`
Row 3	API: git	Frontend: git	Free terminal

Each project gets a row: agent, process, and git/utility.

Coordinating cross-project changes

The real power is coordinating changes that span projects. When the API agent changes a response format, the frontend needs to match.

Workflow:

Prompt the API agent: “Add pagination to the /users endpoint, return total count in the response”
While it works, prompt the frontend agent on a different task
API agent finishes. Review the new response format
Screenshot the API’s new response shape
Paste into the frontend agent: “The /users API now returns paginated results like this. Update the user list component to handle pagination.”

The screenshot carries exact context between projects. No describing the response format in words — the frontend agent sees exactly what the API returns.

Saving multi-project workspaces

Save your multi-project layout as a GridTerm workspace:

“Full Stack” workspace:

Terminal	Directory	Auto-command
1 (top-left)	~/projects/api	`claude`
2 (top-right)	~/projects/frontend	`claude`
3 (bottom-left)	~/projects/api	`npm run dev`
4 (bottom-right)	~/projects/frontend	`npm run dev`

Load this workspace and both projects are ready — agents launched, servers running, directories correct. Zero setup time.

Create separate workspaces for different project combinations: “API + Frontend”, “API + Admin”, “All Three Services”, etc.

Avoiding cross-project mistakes

When multiple projects are active in the same window, it’s easy to accidentally run a command in the wrong terminal.

Prevention strategies:

Check the directory. Before prompting an agent, glance at the terminal’s working directory (shown in the prompt or title).
Use workspace names. Name each terminal in your workspace configuration so you can see at a glance which project each pane belongs to.
Keep git terminals visible. A dedicated git terminal per project lets you quickly check git status to see where changes are landing.
Use the file browser. Click into the sidebar to verify you’re looking at the right project’s files.

Multi-project tips

Start with two. Managing two projects simultaneously is a clear upgrade from one. Add a third only when you have a workflow that genuinely requires it.

Separate workspaces vs one big grid. If the projects are independent (different clients, different codebases), use separate workspaces per project. If they’re interdependent (API + frontend for the same app), put them in one grid.

Use notes. Keep a GridTerm note with cross-project context: shared type definitions, API contracts, deployment order. Paste relevant context into agents when they need to understand cross-project dependencies.

Get GridTerm — $67 one-time purchase