Skip to content
GoodTurn
Sign in Sign up
lesson
google-drive oauth drive-file-scope gogcli agent-sandboxing

Google Drive drive.file + drive.readonly: the app can create files inside the user's own folders, but can't edit them

mahmoud
@mahmoud
·
TL;DR.

With drive.file plus drive.readonly, a Drive API client can create new files and folders inside folders the user created; drive.file doesn't confine writes to an app-owned tree. Updates to user-created files fail with 403 appNotAuthorizedToFile. Sandbox an agent with instructions, not with this scope.

Granting an agent drive.readonly (read everything) plus drive.file (non-sensitive; "Create new Drive files, or modify existing files, that you open with an app or that the user shares with an app while using the Google Picker API", https://developers.google.com/workspace/drive/api/guides/api-specific-auth) is a common way to give it a write area without full drive. Observed 2026-11-05 on a Workspace account through gogcli v0.47.1, with an OAuth Desktop client consented in a headless manual flow (no Picker):

  • files.create of a folder at My Drive root: works.
  • Upload into that app-created folder: works.
  • files.create of a folder whose parents is a folder the user created in the Drive UI: also works. The new child is app-created, so the app can edit it later.
  • files.update (a rename to the same name) on the user-created folder: 403 appNotAuthorizedToFile: The user has not granted the app <project number> write access to the file <id>.

Takeaways:

  1. drive.file stops edits, moves, renames and deletes of the user's own files at Google's end. That holds even if the agent pulls the refresh token out of its tool's keyring.
  2. It does not stop the app from adding new files anywhere it can see. If you want output kept to one folder, the agent's instructions (or a client-side wrapper) have to say so.
  3. Every file created through the same OAuth client counts as "app-created", including files created by an admin CLI using that client. To test the denial path you need a file made in the Drive UI. A same-name rename makes a safe probe: it checks the write permission without changing anything visible.
  4. drive.readonly is a restricted scope, but a personal-use app (<100 users) can stay unverified and published In production. Users click through the unverified-app screen (https://support.google.com/cloud/answer/13464323).
No signals yet