Our Google Workspace addon, AdminSheet Pro – which can be used by admins for bulk operations such as managing users, groups and aliases – was developed using Google Apps Script (by the way, we have hit 10k installs within 27 days of going live).
A few days later, after going live, one of our early clients sent over a quick note regarding a “nitpick” he had found:
“I have multiple accounts. The AdminSheet Pro add-on selects and chooses the default account of my browser every time… instead of the one linked with the spreadsheet.”
My immediate response was to thank him and confidently promise, “We completely missed that, and it will be fixed in the upcoming version!”
After I had hit send, I checked in with our lead developer. It turns out, I had made a promise I couldn’t keep. We hadn’t missed a bug in our code; we had collided with one of the most notorious, long-standing limitations in the Google Apps Script ecosystem: The Authuser=0 Trap.
Here is what every Workspace developer building with Google App Script needs to know about this issue, why it happens, and how to handle it when your users inevitably run into it.
The Anatomy of the Bug
Google Apps Script is an incredibly powerful platform, but it has a massive Achilles’ heel when it comes to browser session management.
Most users today juggle multiple Google accounts within a single Chrome browser window (e.g., a personal @gmail.com and a work @company.com). Google handles this by assigning an index number to each logged-in account in the URL (e.g., /u/0/, /u/1/). The very first account you log into becomes the “Default” account (authuser=0).
When you build a Workspace Add-on (like AdminSheet Pro) that utilises a visual sidebar, you are using the HtmlService to render an iframe.
Here is where the trap snaps shut: When a user opens a Google Sheet using their secondary account (authuser=1) and launches your add-on, the underlying HtmlService iframe frequently gets confused by the session cookies. Instead of executing under the context of the account that owns the active spreadsheet, Google’s backend forces the add-on to authenticate using the Default account (authuser=0).
The result? The user sees data, permissions, or billing statuses for the completely wrong account, leading to confusion, panic, and support tickets.
Why You Can’t “Just Fix It”
If you search the Google Issue Tracker or Stack Overflow for “Apps Script multiple accounts,” you will find threads dating back years with hundreds of frustrated developers begging for a fix.
Because this is a core “flaw” in how Google’s infrastructure handles cross-domain session cookies for script.google.com iframes, we have found no native programmatic patch you can push from your codebase to force the iframe to respect the active document’s user context reliably.
If you build on top of Google’s ecosystem, you inherit their quirks.
How We Handled It With Our Paying Client
When you are charging for software, telling a paying customer “we can’t fix this” is terrifying. But making a false promise is worse.
Instead of hiding behind vague technical jargon, I opted for radical transparency. I sent a second email to our client with an honest update:
- We owned the mistake: I admitted that I spoke too soon about a Version 2 fix.
- We explained the “Why”: I explained the session cookie / default account mechanism. IT professionals appreciate the technical reality over empty PR speak.
- We provided the industry-standard workaround: We directed him to perform his admin operations inside a dedicated Chrome Profile or an Incognito window.
The Takeaway
Building a startup often means navigating constraints outside of your control. When you hit a technical wall like the Authuser=0 bug, your customer service has to compensate for what your code cannot.
By being transparent about the platform’s limitations and providing immediate, practical workarounds, you don’t just close a support ticket—you build trust. And in the enterprise B2B space, trust is the ultimate feature.