Several Repositories, One Coding Agent Setup

Working across several repositories does not require several independent coding agent setups. The useful split is between shared access settings and repository-specific instructions. Keep credentials, endpoint configuration, and everyday defaults in one place; keep build commands, architectural constraints, and review rules close to the code they describe.

This walkthrough uses Claude Code as the example client. The same separation works with Codex or Gemini CLI, although each tool has its own configuration format and instruction-file conventions.

§ 1. Define what should be shared

Start with a small common baseline: one provider endpoint, one securely stored API key, a default model, and a consistent permission policy. Do not put repository paths, test commands, or deployment credentials into this baseline.

Vana API provides one endpoint at https://api.vanaapi.com with OpenAI-compatible access, Anthropic Messages, and Gemini native protocols. That lets different supported clients use the same provider without forcing every tool through the same protocol. Create a Vana API account and generate an API key for your development environment.

Usage is billed per real token with no monthly fee. A shared provider makes access consistent, but each agent session still has its own context and token usage.

§ 2. Configure the agent outside your repositories

For Claude Code, set ANTHROPIC_BASE_URL to https://api.vanaapi.com and ANTHROPIC_AUTH_TOKEN to your Vana API key in the environment used to launch the tool. Use the model identifier documented by Vana API for your chosen model rather than assuming its display name is the identifier.

Store the key in your operating system's secret manager or an approved credential store. If your environment uses a private shell configuration file, ensure it is not tracked or copied into project templates. Check for existing provider variables that could conflict with the new setup.

Run a small, non-sensitive request before opening a real task. Confirm that authentication, model selection, and billing behave as expected. Repeat this check in containers or remote development environments, which may not inherit your local shell settings.

§ 3. Keep shared instructions short

Use your agent's supported user-level instruction mechanism for rules that genuinely apply everywhere. For Claude Code, this can be your user-level CLAUDE.md. Keep the contents focused on working habits rather than project knowledge.

• Read repository instructions before editing files.
• Explain the intended change before making broad edits.
• Do not access secrets or run deployment commands without approval.
• Report checks that ran, checks that failed, and checks that were skipped.

Avoid copying the same large instruction document into every repository. Duplicated guidance drifts, and unnecessary context adds token usage without necessarily improving results.

§ 4. Add a local contract to each repository

Place repository-specific guidance in the instruction file your chosen agent supports. In Claude Code, use a repository-level CLAUDE.md. If teammates use different agents, maintain the corresponding files deliberately; do not assume one filename works across all clients.

Document the package manager, installation steps, lint and test commands, generated-file rules, and important architectural boundaries. Include any conditions for running integration tests, especially when they require external services or paid resources.

Keep this file factual. A backend repository might require a database migration check, while a frontend repository might require component tests. Those differences belong locally, not in the shared agent configuration.

§ 5. Start each task in the right repository

Launch the agent from the repository root and give it a bounded task. Ask it to read the local instructions, identify affected files, and propose a verification plan before editing.

Shared configuration does not mean shared memory. Start a fresh session when switching repositories unless the task intentionally spans them. For a cross-repository change, identify the participating repositories and permitted operations explicitly. Use a short handoff note covering interface changes, version requirements, and outstanding checks instead of relying on conversation history.

§ 6. Verify the workflow before standardizing it

Try one small change in each repository. Check that the agent follows local instructions, stays within the intended directory, and runs the correct validation commands. Review the diff yourself before committing.

Once the workflow is reliable, document how teammates obtain credentials and install the shared baseline without copying anyone's secret. The result is one maintainable access setup, with each repository retaining the instructions and boundaries it needs.