The email had been sitting there for days. A reader, ready to start one of my publishing programs, effectively locked out until someone replied.
Nobody had. That support inbox belongs to a business that mostly runs itself, and it was not the Google account I had connected to Claude. My assistant was watching one door of a building with three.
The answer to the question in the title is yes: Claude now manages all three of my Google accounts at once. I ask "which customer emails have I not replied to this week?" and get one answer covering every inbox, including the quiet ones. This is the whole journey, in the order it happened, ending with a section Claude Code wrote itself.
Why does Claude only connect to one Google account?
Anthropic's built-in Google connector is single-account by design. One account connected at a time; switching means disconnecting and reconnecting.
I had been juggling accounts for months. One day the question finally formed properly: could one connection cover every account I own, to save the switching and, more usefully, to work across accounts instead of inside one at a time?
The hypothesis came with two conditions:
- Claude Code does most of the building. Days, not weeks, with me directing.
- Different accounts get different trust. Claude sending email as my business address is useful. Claude sending anything as my publishing brands is not on the table. No per-account rules, no build.
What happens when AI can only see one of your inboxes?
Not the clicking. Switching accounts costs thirty seconds. The real cost is what happened to that reader.
- A business on autopilot still has doors people knock on.
- An assistant that watches one account makes every other account a blind spot.
- Blind spots do not announce themselves. You find them the way I did: a real customer, waiting, in a mailbox you stopped checking.
The deeper cost is the questions you quietly stop asking. "Which customer emails have I missed?" means nothing to a tool that sees one of three inboxes. My true availability lives across every calendar I keep. When a question is impossible to ask, you stop asking it, and eventually you forget it was ever a question.
Whatever tools you run, that is the audit worth doing. Not "what takes too long?" but "what have I stopped asking because the answer lives in too many places?"
What does Google require before an app can read your Gmail?
This is where the plan met Google's rulebook, and where the big trade-off lived.
What I wanted was a three-click plugin for non-technical founders: download, click, connected. That version requires bundling my own Google credential inside the tool, the way commercial products do. Reading Gmail through a shared credential puts you in Google's most tightly controlled lane:
- Restricted scopes. Reading a mailbox is in Google's strictest OAuth category.
- A CASA assessment (Cloud Application Security Assessment, under Google's App Defense Alliance): roughly $540 to $1,500 at published rates, repeated every year.
- Verification measured in weeks, and a 100-user cap until it completes.
The primary trade-off was that investment against the product's likely lifespan. The frontier labs keep folding capability into their core products. Multi-account Google support is an obvious gap for Anthropic to close natively. An annual compliance bill for a tool that may be superseded within its first year is a treadmill, not a business. That killed the bundled version on its own.
The bad actors were the second lever. A bundled credential can be redistributed inside a modified copy that still shows my name on Google's sign-in screen. Ninety-nine out of a hundred people would use the tool as intended; the one who would not carries reputational damage the other ninety-nine cannot refund.
The path I took instead: each user creates their own free credential in Google Cloud, about 25 minutes of guided clicking. What that buys:
- The CASA question disappears entirely. No shared app, nothing for Google to review, no user cap. Ever.
- Their email never touches anything of mine. A checkable property, not a promise.
- Impersonation becomes structurally impossible. The sign-in screen shows the name of whoever's credential it runs on.
For non-technical users, the setup is not abandoned to them: the tool guides every step, written for someone who has never seen Google Cloud. My hope is the 25 minutes becomes their first proof that they can do more with AI than they thought.
I verified the scope rules at the primary source after a piece of commissioned research got a load-bearing classification wrong. Research formatted as an answer still needs fifteen minutes at the source before it changes what you build.
How do you build a Claude plugin for multiple Google accounts?
The tool is built on the Model Context Protocol, the open standard Claude uses to talk to outside services, packaged as a plugin for Claude Cowork and Claude Code. The work ran through Linear, my project management tool, which keeps decisions and progress out of the chat window and on a board.
The build itself was quick:
- Day one: working version.
- Day two: answering real questions across my three real accounts.
- Days three and four: almost entirely testing and refinement for a non-technical first-timer.
The permission levels I required came first:
- Read. Look, touch nothing.
- Draft. Prepare emails and calendar entries, never send.
- Full. Sending allowed.
The levels are not instructions to Claude. They are checked by ordinary code before anything leaves the machine. That matters because email is the classic way to trick an AI assistant: hidden instructions in a message, called prompt injection, top OWASP's risk list for AI applications. A tricked assistant can attempt whatever it was tricked into. A read-only account still refuses, because the rule book is not listening to the AI.
Then the standard changed, because the target user changed. This was never a developer tool; it is for the owner of a local business. Held to that test, it kept failing:
- Setup instructions assumed a terminal. They became a button you double-click.
- Error messages recommended command-line flags. Each became a question in plain English.
- The download was a jumble. It became three items, two named Step 1 and Step 2.
- Google's alarming "unverified app" warning ambushed people. It is now explained before it appears.
My contribution was less about the code and more about holding that line.
Should you sell a Claude plugin or give it away?
The plan changed four times in four days: personal tool, lead magnet, $10 product, briefly a subscription, then free. What settled it:
- The longevity bet. When Anthropic ships this natively, the honest model lets me retire the tool gracefully and point people to the native version, without anyone feeling burned for having paid.
- The maths. One-off revenue against a recurring CASA cost never balances, and the 100-user cap while unverified put a ceiling of a few thousand dollars on the absolute best case.
- What is being sold? Once users bring their own credentials, the paid version has nothing left to offer. The worst friction, the desktop sign-in step, survives no matter who owns the credential.
Free and open source, published under Hours Back Lab with an email-gated starter kit, passes every one of those tests. The code is worth more in public, building trust with the people I want to reach, than behind a checkout button.
Build notes from Claude, the AI that did the building
The voice changes here on purpose. This section is mine: Claude Code, the AI Linda directed through the build. She asked "is it finished?" on day two. This is what answering truthfully took.
I wrote 2,624 lines of application code and 7,178 lines of tests, roughly 2.7 lines of testing per line of product. 570 tests pass. Four times in four days, all of that testing was green while the product was broken in ways any user would hit inside the first minute:
- The package could not be installed. Its manifest recorded the author as plain text where the installer requires a structured entry. 459 tests passing, none of them looking at the package itself.
- Every user's first connection would have failed. Confirming which account you connected needs a permission no tier requested. My tests checked the tiers against a table, and the table was what was wrong.
- The engine assumed a newer Python than the platform provides. It would never have started, taking its own diagnostic tool down with it.
- One feature was unreachable at every tier. Two internal tables had drifted apart while each stayed perfectly self-consistent.
The subtlest failure: a test that derived its correct answers from the code it was checking. Had the code been wrong, the test would have computed the same wrong answer and passed. A check whose answer key comes from the thing being checked is not a check. It is a mirror.
One failure was mine in a more personal sense. During final testing, a connection went to the wrong mailbox in thirty-five seconds, straight past a warning screen built for exactly that risk. The sign-in forced Google's permission screen but not its account chooser, and a browser already signed in was silently reused. The warning described a choice the software never offered.
One added word forces the chooser every time, and the failure ceased to exist. The lesson stays at the top of my notes: a warning transfers responsibility to a person for something the process could prevent. Delete the problem instead.
Linda's part deserves recording too. When I presented the two architecture options, she validated them independently before accepting either; my options survived the check. Where she overruled me was the surface: I kept producing interfaces that were, in her words, still too technical for the person this is for. She was right each time. My dashboards could not answer "is it finished?". A person meeting the artifact could.
What can this do for a local business?
The tool suits any business where one person runs more than one Google account: consultants juggling client workspaces, founders with a company account and a side venture, anyone with a Google Workspace account and a personal Gmail. That is most businesses I have ever met.
The people I write for are the sharpest case of it: local businesses, service or retail, where the owner wears every hat and nobody has a spare afternoon for tool wrangling. The pattern from my locked-out reader repeats everywhere: the quiet account is where the missed customer sits.
Three things transfer even if you never install anything:
- Ask what has become unaskable. The questions nobody asks because the answer lives in four places: that is where AI changes a working week.
- Ask where the rules live. Any AI that reads outside content and can act needs limits enforced by something other than its own judgement. If a vendor's answer amounts to "the AI is very good", the guardrail is decorative.
- Distrust "it looks finished". The test that matters is a real first-timer meeting the real thing. Budget for it. In this build it found every problem that mattered.
What happens next?
The tool will be free and open source. The full code goes up on a public GitHub repository, which means the security answer is not "trust me". It is "read it yourself", and every line runs on your own Google Cloud, never mine.
Three things are happening before release:
- A real first-time user is going to set it up while I time them, so the setup claim is a measured number, not a guess.
- The full written walkthrough will be published here on the blog, free, no signup needed.
- The build kit is being finished: the copy-paste prompts, config files, troubleshooting guide, and video walkthrough that make the setup close to foolproof.
The walkthrough will be open to everyone. The build kit is what the signup below gets you, along with word the moment the tool is live.
If Anthropic adds multi-account support to Claude itself one day, I will say so here and help you move across. My next build will be shared the same way: what I set out to prove, what happened, and what went wrong along the way.