Managing AI Coding Agents Across Multiple Projects
Most developers don’t work on a single project. You’ve got the main app, an API, a shared library, maybe a marketing site. Running AI coding agents across all of them simultaneously is where the real productivity gains come from — but it requires organization.
The multi-project problem
When you’re working across projects in a single terminal, the workflow is:
cdto Project A- Run Claude Code, do some work
cdto Project B- Run Claude Code there
- Forget which terminal is which
- Accidentally commit changes to the wrong project
With multiple terminals visible in a grid, each project gets its own dedicated panes. You never cd between projects in the same terminal.
Workspace-per-project approach
The cleanest strategy is a GridTerm workspace for each project.
“API Backend” workspace (2x2):
| Terminal | Directory | Auto-command |
|---|---|---|
| Top-left | ~/projects/api | claude |
| Top-right | ~/projects/api | npm run dev |
| Bottom-left | ~/projects/api | (git/testing) |
| Bottom-right | ~/projects/api | claude |
“Frontend App” workspace (2x2):
| Terminal | Directory | Auto-command |
|---|---|---|
| Top-left | ~/projects/frontend | claude |
| Top-right | ~/projects/frontend | npm run dev |
| Bottom-left | ~/projects/frontend | (git/testing) |
| Bottom-right | ~/projects/frontend | npm test --watch |
Switch between projects by loading a different workspace. One click, entire context switches — directories, running processes, agents.
Multi-project single workspace
Sometimes you’re working across projects that interact — an API and its frontend, or a library and the app that consumes it. In that case, use one larger workspace with terminals split by project.
“Full Stack” workspace (3x3):
| Column 1 | Column 2 | Column 3 | |
|---|---|---|---|
| Row 1 | API: Claude Code | API: dev server | API: git |
| Row 2 | Frontend: Claude Code | Frontend: dev server | Frontend: git |
| Row 3 | Shared lib: Claude Code | Tests (integration) | Free terminal |
Each row is a project. You can see all three at once and prompt agents that need to make coordinated changes.
Keeping changes separate
The biggest risk with multi-project agents is cross-contamination — accidentally making changes to the wrong project or committing work in the wrong directory.
Rules:
- Each terminal should be
cd’d to one project and stay there - Never run an agent from a parent directory that contains multiple projects
- Keep git terminals visible so you can check status between prompts
- Use GridTerm’s file browser to verify you’re looking at the right project
Cross-project coordination
When Agent A’s changes in the API require matching changes in the frontend:
- Let Agent A finish the API changes
- Review the API changes in the API git terminal
- Screenshot the new API response format
- Paste into the frontend agent: “The API response for /users now looks like this. Update the frontend to match.”
The screenshot carries the context between projects without you having to describe the changes in words.
Using notes for project context
GridTerm’s notes are useful for keeping multi-project context:
- “API returns user objects without the
passwordfield now (changed 4/3)” - “Frontend expects auth token in
Authorization: Bearerheader” - “Shared types are in packages/types — both API and frontend import from here”
When you start an agent session, paste relevant notes into its context so it understands the cross-project relationships.
Practical patterns
Monorepo
If all your projects are in a monorepo, point different agents at different workspace directories:
packages/apiin terminals 1-3packages/webin terminals 4-6- Root level for integration tests in terminals 7-9
Microservices
Each service gets a row in the grid. Two or three services visible at once. Use workspaces to save different service combinations for different tasks.
Library + consumer
Agent 1 modifies the library. Agent 2 updates the consumer app. Keep a terminal running the consumer’s tests — when the library changes, run tests immediately to catch breakage.