Keep MCP Connector Authorization in One Place — A Solo Dev Design That Survives Growing Integrations

One morning a Cowork scheduled task had quit overnight, leaving nothing but "could not connect to the connector." It had been running fine the day before. The cause: I had rotated the token for that server on the Claude Code side, but the configuration Cowork reads still held the old credential. When the same connector is written separately in each client, this kind of mismatch happens quietly.

The "enterprise managed MCP connectors" Anthropic added on 2026-06-20 remove exactly this mismatch at the structural level. An administrator provisions a connector once, and from then on users get it zero-touch on first login, with authorization centralized across Claude chat, Claude Code, and Cowork. It is an enterprise feature, but the design principle underneath it — keep a single source of truth for how each integration is authorized — is most valuable precisely when, as an indie developer, your list of integrations keeps growing.

Why scattered configs become silent failures

MCP connector settings duplicate themselves if you let them. Claude Code's .mcp.json, the Cowork-side configuration, the connector list in chat — it is easy to write the same hookup to GitHub or Stripe in each of those places. Right after you write them, they are identical, so nothing surfaces.

The trouble appears when you update only one of them: you rotate a token, change an endpoint, narrow a scope. Any client you forgot to update keeps running on the old authorization and only fails the day access is finally denied. Running four sites on autopilot, my list of integrations keeps growing, and I have stepped on this "one of them is stale" state more than once. What makes it nasty is that the error is just a 401 or "could not connect" — the tooling never tells you which configuration is the source of truth.

That single point is what managed connectors solve. If there is only one source of truth, there is only one place to update, and the clients cannot drift apart.

Decide on a single source — choosing scope

The starting point for reproducing that property as a solo developer is to decide, up front, where the source of truth for a connector definition lives. In Claude Code, where you put .mcp.json changes its scope.

• User scope (under your home directory, e.g. ~/.claude.json) — shares the same connector across every project on that machine. For indie work that spans multiple repositories, this is effectively your source of truth.
• Project scope (a .mcp.json at the repository root) — a connector for that project only. Place one here solely when you want a team or a public repository to declare "this project uses this."

When in doubt, push anything used across projects into user scope and leave only project-specific connectors in the repository; that split keeps duplicates from forming. I consolidate the connectors shared across all four sites into user scope, and each repository's .mcp.json holds only the targets that one site alone touches.

// ~/.claude.json (user scope = source of truth for cross-project connectors)
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      // Do not hardcode the token; reference an environment variable (next section)
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    }
  }
}

The discipline that matters here is this: once you have chosen the source of truth, never write the same definition a second time in another client. When you use the same server from Cowork or chat, you reference the same environment variable and the same credential — you do not paste in a fresh token.

Don't embed credentials inline

The key to getting the full benefit of "one source of truth" is how you hold the authorization itself. If you hardcode a token into .mcp.json, then no matter how single your config is, that file has become a copy of the credential. Opening the file to rewrite it on every rotation is exactly where missed updates breed.

So write only an environment-variable reference in the config file, and keep the actual token in one place in the environment.

# The source of truth for credentials lives only here (e.g. ~/.config/claude/secrets.env)
export GITHUB_TOKEN="ghp_..."     # the real value exists only in this file
export STRIPE_API_KEY="sk_..."
 
# Config files only reference these. Rotation means rewriting this env, and every client picks it up.

With this in place, updating a token becomes "rewrite one secret location." Each client's config holds only a reference, so there is no longer any client that can forget to apply the update. The "one of them is stale" failure from the opening is almost entirely gone after this single move. Remember to keep the secrets file in .gitignore so it never lands in the repository — once a credential enters your commit history, you are rotating it from scratch.

Distrust "they should all match" — make drift checks a habit

Even with a design that keeps a single source of truth, people create exceptions by hand. You temporarily added a connector under a project, you pasted a separate token for testing — leave those stopgaps in place and, before you know it, your source of truth has quietly become two. A light check that surfaces configuration drift now and then catches this early.

# List any .mcp.json that slipped under a project directory
find ~/projects -name ".mcp.json" -not -path "*/node_modules/*"
 
# Pull just the server names from each config and eye-check for unexpected duplicate definitions
for f in $(find ~/projects -name ".mcp.json" -not -path "*/node_modules/*"); do
  echo "== $f =="
  grep -o '"[a-zA-Z0-9_-]*":[[:space:]]*{' "$f" | head
done

The check itself takes a few seconds. The point is to verify, on a regular cadence, that connector definitions are not multiplying outside the source of truth. When you find one, you either fold it back into the source of truth or decide whether it really is project-specific and tidy up accordingly. Where managed connectors guarantee centralization in the administrator's hands, in indie work you are also that administrator. That is exactly why an occasional inventory is the condition for keeping centralization alive.

Where the platform won't centralize for you, set your own source of truth

Enterprise managed connectors deliver "connect once, reuse from every client" inside a company's administrative boundary. It is not a feature that lands in your lap as a solo developer, but the core of the design — keep a single source of truth for how each integration is authorized, and let every client merely reference it — transfers directly into the environment you already have.

There is not much to it. Consolidate cross-project connector definitions into user scope, keep tokens out of configs and in a single environment source of truth, and check for drift now and then. Those three habits alone make the silent "one of them is stale" failure far less likely as your integrations grow. I think of it as quietly turning a setup where each new connector makes operations heavier into one where each addition makes the whole thing easier to keep tidy.

For the surrounding design, see Putting MCP Servers to Practical Use in Claude Code; for permissions in unattended runs, Narrowing the MCP Tools You Hand an Unattended Agent; and for the bigger picture of orchestrating several services, Cowork × Multi-MCP Orchestration.

If you run a growing set of integrations the same way, I hope this gives you a reason to take inventory.