gas-fakes includes a sandbox feature in an emulation of Apps Script on Node that allows you to control file access and manage test artifacts
The rise of generative AI tools like the Gemini CLI has unlocked incredible potential for automating Google Workspace, allowing developers to generate Google Apps Script code from simple, natural language prompts. However, this power comes with a significant security challenge: how can you safely execute code generated by an AI without granting it broad, potentially risky permissions to your Google Drive?
In a brilliant example of community collaboration, two distinguished developers, Bruce Mcpherson and Kanshi Tanaike, have provided a powerful solution to this very problem. Their combined work showcases an elegant architecture for creating a secure “Fake-Sandbox,” allowing developers to test and run AI-generated code with confidence.
The Problem: The All-or-Nothing Permission Model
At the heart of the issue is that Google Apps Script’s core services often require sweeping permissions. For example, a script designed to organise files often needs the https://www.googleapis.com/auth/drive scope, which grants it sweeping access to all of a user’s files and folders in Google Drive. This presents a clear risk when running code from a source you don’t fully control, as an unintended command could have far-reaching consequences.
Bruce Mcpherson’s Foundation: gas-fakes
The technical cornerstone of the solution is gas-fakes, a powerful Node.js library created by Bruce Mcpherson. This library ingeniously emulates a Google Apps Script environment locally. It works by translating familiar Apps Script calls (like SpreadsheetApp.create()) into their equivalent, direct Google API requests. The library already provides extensive support for the most-used services, including SpreadsheetApp, DocumentApp, DriveApp, and SlidesApp, along with their advanced service counterparts.
This abstraction is the key. By funnelling actions through the underlying APIs, gas-fakes makes it possible to work with more granular, file-specific permissions—a level of control not available with the standard Apps Script services.
Kanshi Tanaike’s Vision: The “Fake-Sandbox”
Seeing the potential of this library, Google Workspace Developer Kanshi Tanaike authored a detailed feasibility study proposing its use as a “Fake-Sandbox.” Tanaike demonstrated how gas-fakes could be integrated directly into the Gemini CLI workflow.
His approach is both simple and effective:
Generate Code: A user provides a prompt to the Gemini CLI (e.g., “Create a new Google Sheet and add the value ‘Hello, World’ to cell A1”).
Execute Locally: The generated Apps Script code is then executed locally on Node.js.
Translate and Secure: The gas-fakes library intercepts the Apps Script commands, translates them into permission-controlled Google API calls, and executes them securely.
Crucially, any files created during this process are contained within the sandbox session. At the end of the run, a simple command (ScriptApp.__behavior.trash()) automatically cleans up by moving all created files to the Google Drive trash, leaving the user’s Drive pristine.
Taking it Further: Granular Controls
Building on this concept, the gas-fakes library now includes even more sophisticated sandbox controls, as detailed in a follow-up post. Developers can now implement:
Whitelists to grant read-only or write access to specific, pre-existing files.
Per-Service Rules to disable entire services (like DocumentApp) or restrict a service to a specific list of approved methods.
Ultimately, this work provides a vital safety net for innovation. It gives developers the confidence to experiment with AI-generated code, knowing that their core data is protected by a robust and highly configurable sandbox. This practical solution removes a major barrier to entry, establishing a clear blueprint for safely embracing the next wave of Google Workspace automation.
To dive deeper into this solution check out the source links below:
