Give your AI agent its own access to your Google Drive and Google Sheets. You open one link, log in with your Google account, and you are done. No clicking through the Google Cloud console, no app to register, nothing pre-configured.
Status: early (v0.2.1). All commands work against a real personal Google account. Relay mode (Keyring) was tested end to end with a personal and a Workspace account, including a shared drive. Linux, macOS and Windows binaries are on the releases page.
Tools that talk to Google Drive from a terminal usually borrow a shared login app (rclone's built-in client, for example). Those shared apps are slow, rate-limited, and going away: Google will start charging for heavy API use on them later in 2026, and rclone is retiring its built-in client because of it (rclone forum, Google notice).
The alternative today is "make your own client ID", which means the Google Cloud console, a consent screen, a homepage URL and a privacy policy. Most people stop there.
drivekey gives each user their own Google project, created for them by their agent, so they get their own rate limits and nothing depends on a shared app.
Agents: follow AGENTS.md. It is the exact sequence, including error codes.
curl -fsSL https://raw.githubusercontent.com/jerryfane/drivekey/main/install.sh | sh
drivekey login # prints a URL; the user opens it, logs in, copies the code
drivekey login --code CODE
drivekey setup # creates the user's own Google Cloud project, enables Drive + Sheets
drivekey ls # done| Step | Who | What |
|---|---|---|
| 1 | agent | Installs drivekey and Google's gcloud CLI. |
| 2 | user | Opens the link the agent shows, logs in with their Google account, pastes back the code. |
| 2b | user, new Cloud accounts only | Opens https://console.cloud.google.com once and accepts the terms. |
| 3 | agent | drivekey setup creates a project for the user and enables the Drive and Sheets APIs. |
| 4 | agent | Works as the user from then on. |
Everything the agent creates is owned by the user, in their own Drive.
| Command | What it does |
|---|---|
ls, info, get, put, mkdir |
List, inspect, download (with --export for Google Docs files), upload or replace contents, create folders. Files in shared drives work too (ls --drive ID lists a whole shared drive). |
drives |
List the shared drives the account is a member of. |
sheet create, sheet tabs, sheet read, sheet write, sheet append |
Work with Google Sheets cell by cell, never by re-uploading the whole file. |
sheet set |
Set one cell, finding the row by a key column and the column by its header name. Refuses to guess. |
changes, watch |
What changed since last time, optionally limited to one folder and everything inside it, or one shared drive (--drive ID). |
status, login, setup, logout |
Account management. |
profile add, profile list, profile remove |
Relay profiles: use a Google account through the Keyring relay (see below). |
Every command prints JSON. Errors go to stderr as {"error": {"code", "message", "hint"}}.
- Login is Google's own
gcloud auth login --enable-gdrive-access, so drivekey never registers or ships an OAuth client. drivekey keeps a private gcloud config (~/.config/drivekey/gcloud, mode 0700) and never touches the user's own gcloud setup. The login runs in a small background helper, so an agent can print the URL in one step and hand over the code in the next. - Own project: every API call sends the user's project as quota project
(
x-goog-user-project), so the user gets their own rate limits. - Tokens: drivekey asks gcloud for a short-lived access token and caches it until it expires. It never reads gcloud's refresh token.
- Written in Go with Google's official client libraries; one binary per platform.
In relay mode the Google login never reaches the agent machine. It lives on the
Keyring host, which adds a short-lived token to each
call. The agent machine needs no gcloud and holds no Google credential; Keyring approves
and revokes each agent role separately.
drivekey profile add personal --role agent-personal --account personal
drivekey profile add business --role agent-business --account business
drivekey --profile personal ls # or DRIVEKEY_PROFILE=personal drivekey ls
drivekey --profile business status # relay health and which Google account answers- A profile stores only the relay URL (default
http://127.0.0.1:7700), the Keyring role and the Keyring account name. Calls go to that role's servicesgoogle-<account>-drive,google-<account>-uploadandgoogle-<account>-sheets. The role's token stays in the relay's own storage. - Always explicit. Once any profile exists, every account command needs
--profile NAMEorDRIVEKEY_PROFILE;--profile directuses this machine's own login. An unknown profile is an error. drivekey never falls back from relay to a local login, or from one profile to another. - Each profile keeps its own change-feed positions, so accounts never share a cursor. Removing and re-adding a profile starts its feeds over.
login,setupandlogoutrefuse for a relay profile (relay_mode): the account is signed in on the Keyring host.profile removedeletes only the local profile; the owner revokes the role in the Keyring dashboard.- Only Drive, Drive upload and Sheets API URLs are sent, each to the matching service of the
same profile. Upload sessions and redirects that point anywhere else are refused
(
relay_route_refused). - Errors:
relay_unreachable(relay or Keyring host down),relay_denied(role unknown, revoked, expired, not granted, or over its daily limit),relay_login_required(Keyring reports that Google requires the account to sign in again on the Keyring host),relay_google_unavailable(Keyring could not renew the token for another reason),relay_token_rejected(Google rejected the token on a write; nothing was applied; run it again). - When Keyring cannot renew an account's token, the error and
statusshow its diagnosis:cause(for examplereauth_required,runtime_unavailable,network_error,unknown),stageandrecovery, plus a next step. Onlyreauth_requiredwith recoveryowner_reauthasks the owner to sign in again; unknown or missing diagnoses never do. drivekey does not retry these failures. - The role needs these Keyring grants: Drive
GET,POSTon/about,/files,/changes,/drives; uploadPOST,PATCHon/files(PATCHonly forput --replace); SheetsGET,POSTon/spreadsheets.
- New Cloud accounts must accept the Cloud terms once in the browser. Creating a project from the CLI fails until they do.
- No robot (service) account. Service accounts created after 15 April 2025 cannot own Drive items, so they cannot create files in a personal Drive (details). drivekey uses the user's own login for everything instead.
- The login is powerful: it covers the user's Google Cloud and their whole Drive.
It is stored only in drivekey's private directory (mode 0700 on Linux and macOS; on
Windows it relies on the user profile's default permissions, so if you set
DRIVEKEY_HOMEorXDG_CONFIG_HOME, keep it inside your profile). Revoke it withdrivekey logout, or at https://myaccount.google.com/permissions ("Google Cloud SDK"). - gcloud is required for the login step (about 500 MB). It is the only way to log in without registering an app.
| Question | Result |
|---|---|
Drive-enabled gcloud login from a link, no "app blocked" screen? |
Yes. |
| Project creation before accepting Cloud terms? | Fails: Callers must accept Terms of Service. One console visit needed. |
| Robot (service account) key creation on a personal account? | Works; no org policy blocks it. (Robot later dropped from the design.) |
| User login creates folders, Sheets, uploads? | Yes, owned by the user. |
| Robot edits Sheet cells / replaces file contents / sees later files? | Yes. |
| Robot creates files (upload or empty Sheet) in the shared folder? | No: storageQuotaExceeded. It can create subfolders. |
| User login edits Sheet cells, replaces file contents, sees changes? | Yes. |
| User calls counted against the user's own project? | Only when x-goog-user-project is set. Without it they count against gcloud's shared project, which already returned 429 rate limits during the test. |
| Login still valid later, with no new login? | Yes on day 1 and day 7 (login 2026-10-04, checked 2026-10-05 and 2026-10-11). Day 30 was not measured: the test login was removed on 2026-10-16. |
Design consequences:
- No robot: the user's login does everything, including creating files.
- Every API call names the user's project as quota project.
gcloudis only used for login and project setup.
To be decided.