Bring your own Claude, or use the client's?

ProxyLoom — Sat, 22 Aug 2026 13:36:05 +0000

If you run several client engagements in parallel, you have probably hit this fork at some point.

When you hand work to Claude, do you keep one Claude of your own and connect each client's systems to it? Or do you work inside a Claude that each client provides?

I only ever did the first. It wasn't that I hadn't heard of the second. I came to Claude as a developer, for application development, and in that world each client's environment is already separated as a local repository. A second Claude isn't needed there — it would only get in the way. But these days I do more than development, and that has changed things.

A: Bring your own Claude

You hold one Claude subscription of your own and connect your clients' Google Drive, Slack, Notion and Miro accounts to it.

In this setup you would normally use the Claude desktop app. There is no reason to go out of your way to work in the browser.

Inside Claude, Projects keep each engagement's context apart: the background, how you like instructions written, the reference material. Each stays inside its own project, which in practice is separation enough.

And because it is the desktop app, you get Claude's full feature set. Working with local files, driving your computer, sending instructions from your phone. Those are the features that make an agent worth handing work to.

There is exactly one thing that hurts. A Claude connector holds one account per service. If Client A's Google Drive is connected and you try to add Client B's, you disconnect Client A's. So whenever two clients use the same SaaS, every switch means either redoing that setup, or giving up on letting Claude touch it and putting a human in the middle instead — rather than Claude reading a document straight out of the drive, someone downloads it and pastes it in. It works. It is also a steady drip of small, annoying steps.

B: A separate Claude per client

Here you get invited into the client's own workspace and work inside it. To keep each client's Claude apart, this in practice means using Claude in the browser and running a separate Chrome profile per client.

With B, A's problem simply goes away. The Claude accounts themselves are separate, so it does not matter how much SaaS overlap there is between clients. Client A's Claude gets Client A's Google Drive, Client B's Claude gets Client B's. That's all there is to it.

You can also let the client carry the cost. It is not a large amount per month, but it is better on their bill than on yours.

Administration moves to the client too. They issue the account and they revoke it, so when the engagement ends access is cut the same day. And no client's data ever lands in an account of yours.

One thing worth correcting: people sometimes describe this as "the data stays inside the client's tenant." That isn't accurate. In both A and B, the data sits in Anthropic's environment. What B changes is only who administers the account.

So is B better? Not quite.

You lose Claude's full feature set. Local files, driving your computer, instructions from your phone — those assume the desktop app and are not available in the browser. Claude in Chrome will read the tab you already have open using nothing but the browser, but having Claude actually operate Chrome for you is off the table.

Bringing your own toolchain also gets harder. What gets connected to the client's Claude is not your decision. The meeting-notes tool you always use, the MCP servers you wrote yourself, the tools you carry across every engagement — each one turns into a "please let me install this" conversation, and if the answer is no, that part of how you work is gone. You can end up doing the job in an environment that never gets full power out of the agent.

And day to day, the work becomes hopping between Chrome profiles.

About A's one problem

I went with A, and the one and only real problem was the connector's one-to-one limit. "You can't connect Client B's Google Drive while Client A's is connected" — that was the thing I wanted solved. So I built something that keeps a single connection to Claude while bundling multiple accounts behind it. I've released it as ProxyLoom.

You can keep Client A's, Client B's and Client C's Google Drive connected at the same time. Nothing to reconnect, so the setup step at every switch disappears. Instructions that span engagements — "pull last week's minutes out of Client A's Google Drive and work them into the deck for Client C" — go through as written.

There is still one thing it doesn't solve: Claude in Chrome. ProxyLoom handles the connections that go over MCP, but the Chrome that a single Claude desktop can drive is limited to one profile. That comes from how a browser extension works, so no layer sitting outside can fix it. The fix looks like it will come from somewhere else. Claude Code's desktop app already ships an in-app browser, and OpenAI went as far as retiring Atlas and folding its capabilities back into the ChatGPT desktop app and a Chrome extension. Once browser automation lives inside the app and can hold logins there, the premise that you only have one Chrome profile stops applying.

Closing

Neither answer is wrong. But if you support several clients in parallel and haven't yet noticed this fork, it is worth thinking through once. Past three engagements or so, the choice starts to show.

If you're on the A side and tired of reconnecting connectors, give ProxyLoom a try. It's still an open beta, and I'm actively taking requests.

ProxyLoom for Consulting

DEV Community: ProxyLoom

Bring your own Claude, or use the client's?

A: Bring your own Claude

B: A separate Claude per client

About A's one problem

Closing