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
| Option | What it does | Pros | Cons |
|---|---|---|---|
| Use CardService (Workspace Add-on) | Avoid google.script.run completely | Works across apps, account-safe | No custom HTML/JS |
| Switch to Incognito | Single account context | Works instantly | Not user-friendly |
| Educate the user | Detect issue and show alert with workaround | Saves support time | Requires extra logic |
Use .withFailureHandler() | Catch error gracefully | Better UX | Doesn’t solve root cause |
| Fallback to toolbar menus | Trigger server code from onOpen() menus instead | Safer | Limited interactivity |
| Re-auth logic via Apps Script API | Force correct identity usage | Advanced workaround | Harder to implement |
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.