Skip to main content
The Google Drive VFS exposes a Google Drive account as a virtual filesystem mounted at some prefix such as /gdrive/. For Google OAuth setup, see Google Workspace Setup.

Config

To mount a subfolder instead of the whole Drive, set folder_id. The mount root becomes that folder. The folder may live in My Drive, be shared with you, sit inside a Shared Drive, or be a Shared Drive id itself; the drive scope is resolved automatically. Scoped mounts do not surface other shared drives:
Fields marked secret are redacted in snapshots.

VFS.md

The VFS.md an agent reads with Google Drive mounted at /<path>.

Virtual Filesystem

/<path> layout

Supported Unix Commands for VFS

Unix commands work on each path as on a local filesystem, as far as the path supports them:

Limitations of Unix Commands for VFS

Where a path differs from a local filesystem:Run man <cmd> or <cmd> --help for one command’s usage.
Example:
The mount mirrors the actual Google Drive folder hierarchy. The root contains the Drive API root folder plus each Shared Drive visible to the user. Shared Drives appear as top-level directories. Duplicate names receive a [Shared Drive] suffix and, when needed, a numeric suffix. Subfolders appear as directories, and regular files keep their original names.

Synthetic Extensions

Google Workspace files cannot be downloaded as raw bytes, so they are exposed with synthetic extensions and read via their respective APIs: Regular files (PDFs, images, CSVs, etc.) are downloaded directly from Drive. Large regular files use streaming.

Write Support

Under MountMode.WRITE the standard write commands work on regular files and folders: tee, cp, mv, rm, mkdir, rmdir, touch, truncate, and in-place editors such as sed -i. Semantics follow the other object-store mounts (GNU check-then-act: EEXIST on mkdir over an existing name, mv onto a non-empty directory fails with ENOTEMPTY, cp -r merges). Google-native files (.gdoc.json, .gsheet.json, .gslide.json) are read-only as bytes; writing to them fails with EACCES. Mutate them through the gws commands below instead. Drive access is per-item (shared-drive roles, folder-level grants), so a write mount can still hold items you may not edit. A mutation the API denies fails with EACCES (Permission denied) on that operand, like a real filesystem; the rest of the mount keeps working. A write records the md5Checksum (else the headRevisionId) its upload reply names, so a fresh read right after a tee or sed -i downloads nothing. Use MountMode.EXEC if python3 or js should run scripts from the mount.

Writing inside a Shared Drive

A Shared Drive is not a read-only corner of the mount. Every Drive call mirage makes carries supportsAllDrives, so create, write, rename, copy and delete work the same inside a Shared Drive as in My Drive, and the commands above behave identically there. What you may actually do is decided by Drive, not by mirage: a Shared Drive has its own role model (viewer, commenter, contributor, content manager, manager), and some organizations restrict deletion or moving content out of the drive. mirage does not attempt to predict those rules. It issues the operation and reports the answer, so a role that forbids the change fails with EACCES on that operand, exactly like an unwritable item in My Drive. The practical consequence is that a write mount spanning Shared Drives is partly writable, and the boundary follows your roles rather than the mount. If you want a mount that cannot write at all, use MountMode.READ; if you want to scope one to a single drive, set folder_id to the Shared Drive id.

Snapshots

The VFS supports workspace snapshots. Recorded reads capture the file’s Drive revision (headRevisionId), and a loaded snapshot pins reads to that revision via the Drive Revisions API, so replay serves the exact bytes the agent saw. A path the agent wrote carries its write’s token and no revision: loading checks the live file against that token, and replay reads the live file rather than a pinned revision. Google Docs, Sheets and Slides files carry no revision: loading checks them against the live file instead.

Cache

The Google Drive VFS uses IndexCacheStore (same as Slack, Gmail, and other mounts). Index entries store folder IDs, file IDs, and file metadata. File bytes go through the workspace file cache.

Example

See examples/python/vfs/gdrive/gdrive.py for the full working example.

Shell Commands

Standard commands available on the mounted Google Drive tree:

Integration

What Google Drive answers through its own API, so fewer files are read. Integration explains each command. grep -rw and rg -w read only the files Drive full-text search names; every file is read when the search fails or finds nothing. walk_limit: -1 in the mount’s "@all" command limit reads every file instead, since Drive searches the text it extracted, not the bytes grep reads, and indexes a write some time after it lands, so a file that holds the word can be left out: a Docs, Sheets or Slides file (its JSON keys and ids), an office file, PDF or archive, the end of a large file, or a word Drive splits differently (foo.bar).

Acting on Drive

Acting on Drive files by id (create, update, copy, delete, share, export, plus the Docs/Sheets/Slides helpers) goes through the gws CLI when installed.