Handing One Aggregator Key to a Two-Person Claude Code Setup: Per-Developer Config Files Instead of Copy-Pasted Shell Exports

Why copy-pasted shell exports break a shared-key setup

When two developers share one aggregator key, the fastest path is usually a snippet of export lines pasted into a shell profile. It works on day one and causes problems later:

• Each person's ~/.zshrc or ~/.bashrc drifts independently, so you can no longer tell which base URL or model alias a given run used.
• A single shared profile means any change one person makes silently applies to every repo they open.
• Rotation or re-scoping of the key requires editing shells in two places with no record of what changed.
• Debugging "why did the model alias fail" means reading someone else's shell history.

Claude Code reads configuration from the environment and from project files, so the fix is to move settings out of ad-hoc exports and into files with a clear owner.

Separate the concerns: key, endpoint, aliases

Before writing any file, decide what belongs where:

• The key itself — one secret held by both developers, loaded from a local, git-ignored file or a secret manager. Never committed.
• The base URL / endpoint — the aggregator's OpenAI- or Anthropic-compatible endpoint. This is stable and can be checked in per repo.
• Model aliases — how your team names models internally versus what the aggregator exposes. These should live in a versioned project file.
• Per-developer overrides — anything that is genuinely personal (local proxy, extra logging, a scratch model alias).

If you keep these four layers distinct, two people can share a key without sharing a shell profile.

Use per-repo config as the source of truth

Check a project-level config file into the repository so both developers get identical defaults:

• Put the aggregator base URL and the project's model aliases in a config file inside the repo.
• Keep this file free of secrets — it should be safe to review in a pull request.
• When the team changes a model alias, it becomes a normal code change with a diff and a reviewer, not an invisible shell edit.

This is the layer that answers "what does this repo expect from the aggregator?" regardless of who runs it.

Keep secrets in a per-developer file

The key is the only thing that should differ between the two of you, and it should never be in the repo:

• Store the key in a local file that is listed in .gitignore, or retrieve it from your OS keychain or a secret manager at shell start.
• Reference that value via an environment variable that Claude Code and your tooling read.
• Document the expected variable name in the repo's README so both developers wire up the same thing.
• Rotating the key then means updating one local file per person, not rewriting shell profiles.

Layer personal overrides instead of editing shared files

A two-person setup still needs room for individual preferences. Handle that with an override layer:

• Let the repo config define defaults, and allow a local, ignored file to add or replace aliases for that developer only.
• Use this for personal experiments — a new model alias you are testing, a local proxy, verbose logging — without touching what your teammate sees.
• Keep the override surface small and documented, so when something behaves differently you know to check the local file first.

Shell exports remain fine for transient, one-off sessions. They should not be the place where durable configuration lives.

Make the shared key auditable

One key across two people is manageable if you can answer basic questions later:

• Who changed what? Repo config changes are visible in version control; local secret changes are timestamped on disk.
• Which endpoint was used? Because it lives in a reviewed file rather than a shell profile.
• What does this alias resolve to? The mapping is written down in the project config, not inferred from memory.

Consider a short note in the repo describing the alias scheme, so neither developer has to reverse-engineer it.

Costs, credits and why this matters for a shared key

On this aggregator, usage is billed at official model price × 1.3, and contributors who bring in keys are credited official price × 1.1 (premium × 1.2) in USDC. In a two-person setup, clean configuration keeps usage attributable and predictable: if one developer accidentally points an alias at an expensive model, the reviewed config makes that visible before it becomes a surprise.

You top up with USDC on Base and there is no KYC step, so the operational overhead is low — which makes disciplined config the main lever you control.

A short checklist

• Secret key: local, git-ignored file or secret manager, loaded via one agreed variable name.
• Base URL and model aliases: versioned per-repo config, reviewed in pull requests.
• Personal overrides: a separate ignored file, documented and kept small.
• Shell exports: reserved for one-off sessions only.
• README: states the variable names and alias scheme so both developers stay in sync.