To run AI coding agents across several client projects, give each client its own folder, its own instructions file and, when the contract asks for it, its own agent account, then start every agent inside that client’s folder only. Most problems agencies report with agents (wrong conventions, leaked context, surprise costs) come from shared setup, not from the model.
This guide is for small agencies and freelancers who already use Claude Code, Codex or another coding agent on one project and now want it on five. It covers the setup per client, keeping costs visible, reviewing before you deliver, and how to keep all of it in one window.
Why one setup for all clients breaks
A coding agent works with what it can see: the folder it starts in, the instructions files there, and the account it is logged in with. When those are shared across clients, three things go wrong:
- Conventions leak. The agent picks up habits from the last client’s code or instructions and applies them to the next one.
- Costs blur. One account and one usage bar for everything means you cannot tell which client used what.
- Access is wider than it should be. An agent started in a parent folder can read every client folder under it, including
.envfiles.
The fix is boring and works: one boundary per client.
Step 1: one folder per client, and start agents inside it
Keep each client in its own folder, with its own repository:
~/clients/
acme-shop/
dental-clinic-site/
logistics-dashboard/
Always start the agent from inside one client folder, never from ~/clients/. Claude Code, Codex and Gemini CLI all treat the folder you start them in as the project. If you need a second agent on the same client, for example one on a bug fix and one on a new page, give it a git worktree so they do not edit the same files.
Step 2: write one instructions file per client
Every coding agent reads a project instructions file at the start of a session: CLAUDE.md for Claude Code, AGENTS.md for Codex and many others. Put one at the root of each client folder. Keep it short and specific:
# Client: online shop (Shopify theme + Node API)
- Stack: Liquid theme, Node 22, Postgres. Tests: npm test.
- Client style: no new dependencies without asking; Turkish and English copy.
- Never touch: payment settings, /infra, production .env files.
- Done means: tests pass, a pull request with a short summary for the client.
This file is the difference between an agent that guesses and one that follows the client’s rules. When a client changes a rule, change the file, not your prompts.
Step 3: decide on accounts per client
Some clients do not care which account the agent runs on. Others want the work done on an account they pay for, or forbid sending their code to a provider they have not approved. Check the contract first.
When a client needs its own login, give that account its own config folder. Claude Code reads its folder from CLAUDE_CONFIG_DIR and Codex from CODEX_HOME, so two folders mean two logins on the same machine without logging out. Our guide on switching Claude Code accounts shows the manual setup step by step.
Step 4: keep secrets out of reach
Agents read files to understand a project, and .env files are files. Per client:
- keep production credentials out of the working folder; use a development
.envwith test keys; - add the sensitive paths to the instructions file under “never touch”;
- use the agent’s permission settings so it asks before running commands that deploy, migrate or delete.
Step 5: measure tokens per client
If you plan to bill AI usage, or just want to know which client is profitable, measure it per agent and per folder from day one. Two simple rules help:
- set a daily cap per agent, so a stuck loop does not burn a client’s budget overnight;
- use the cheaper model for routine edits and the stronger one only for design and debugging.
Our post on Claude Code usage limits explains how the 5-hour and weekly limits work, which matters once several clients share one subscription.
Step 6: review every diff before the client sees it
Let agents work on a branch and open a pull request. Read the diff, run the tests and check the page yourself. Clients do not pay for code an agent wrote; they pay for code someone they trust checked. A short written summary per pull request also makes the weekly client update easy.
Doing this in one window with AgentVera
The steps above work with plain terminals. The hard part is keeping five clients and ten agents in view. AgentVera is a desktop app for macOS, Windows and Linux that runs Claude Code, Codex, Gemini CLI and other agents side by side, each in a real terminal with your own install and login. For agency work, the parts that matter are:
- A grid per project. Each client folder gets its own set of agents, and you switch between clients without losing their state. See workspace.
- An account per agent. Add accounts in Settings → Accounts and pick one when you create an agent, so a client’s agents always run on the right login. See accounts.
- Token caps per agent. Caps per agent, per turn and per day, a warning at 80%, and at the cap the agent stops but keeps its conversation. See token budgets.
- Code review before delivery. Review the agent’s changes inside the app before they go to the client’s repository. See code review.
The free plan includes up to 18 agents, MCP, Git, Docker, SSH, code review and token savings. Pro is $9.99 a month; if you have never had a trial, your first sign-in to the app turns on Pro for 7 days with no card.
Wrapping up
Agents scale to many clients when each client has a clear boundary: its own folder, its own instructions file, the right account, no production secrets in reach, its own token count and a human review before delivery. Set that up once per client and adding the sixth client takes minutes, not a week of cleanup.
Sources: Claude Code settings, AGENTS.md.