👥 The Multi-Account Trap in Google Workspace Add-ons (And How to Avoid It)
July 11, 2025
If you’re building Google Workspace Add-ons or Editor Add-ons, there’s a good chance you’ve encountered mysterious PERMISSION_DENIED errors, especially when using google.script.run in custom sidebars.
The kicker? The same code works flawlessly for some users, and fails catastrophically for others — without any obvious reason.
Welcome to the multi-account execution context problem.
In this article, I’ll break down:
When and why this error occurs
How to reproduce it
What you can do to avoid it (or at least handle it gracefully)
My own learnings building real-world Add-ons
The error usually looks like this in the browser console or Apps Script logs:
It typically occurs when a client-side script (e.g. inside an HtmlService sidebar or dialog) calls a backend Apps Script function using google.script.run.
But the real root cause is subtler: user identity confusion in multi-account Chrome sessions.
🔍 When the Error Happens
This bug is especially likely when:
You’re using google.script.run inside a custom sidebar or dialog (HtmlService)
Your user is signed into multiple Google accounts in the same Chrome session
The default account in Chrome is not the one that:
Owns the spreadsheet/doc
Authorized the script
Installed the Add-on
It’s more common when:
Using the V8 runtime (Rhino (ES5) runtime will be deprecated in January 31, 2026).
The script accesses services like SpreadsheetApp, DocumentApp, or PropertiesService
Users try your add-on in a company workspace while logged into their personal Gmail too
And what’s worse: it works fine in Incognito or when only one Google account is signed in — making it hard to debug unless you’re specifically testing for it.
🧪 How to Reproduce It
1 – Create a Google Docs/Sheets add-on with a sidebar and a button calling a server-side function:
google.script.run.withFailureHandler(console.error).myFunction();
2 – Have a function that uses DocumentApp, SpreadsheetApp, etc.
3 – Deploy the add-on as a test deployment (editor add-on) and install it in a file
4 – Open that doc while logged into multiple Google accounts.
5 – Ensure you’re not using the correct account as the default in Chrome.
6 – Click the button → Boom: PERMISSION_DENIED.
🛡️ How to Avoid or Handle It
Example of fall-back
google.script.run
.withFailureHandler(function(err) {
if (err.message.includes("PERMISSION_DENIED")) {
alert("⚠️ Access error. Try using this add-on in Incognito, or sign out of other Google accounts.");
}
})
.testPermissionDenied();
🧠 Conclusion: Be Proactive, Not Reactive
This bug has existed for years, and unfortunately, there’s no official fix from Google yet. With the upcoming deprecation of the Rhino runtime (Jan 2026), even more developers will run into it as they migrate to V8.
If you’re shipping an add-on:
Test in multi-account scenarios
Plan your UI strategy: do you need HTML interactivity or CardService reliability?
Include error handling + guidance for users who hit this issue
Don’t wait until users leave 1-star reviews thinking your add-on is broken — build defensively and communicate clearly.