Google Drive as a local disk, S3/WebDAV endpoint and MCP server, in one command.

OnlyDrive is a single exe (the command is gd) that turns Google Drive (a regular Google One or Workspace subscription, no Google Cloud and no API keys) into:

1. A local disk: on Windows, Drive folders show up in Explorer as GDrive-acc1 (X:); on macOS and Linux, gd mount acc1 mounts the account natively at ~/.gd/mnt/acc1 (rclone nfsmount on macOS, no macFUSE needed; the FUSE backend on Linux, where nfsmount would need root)
2. An MCP server: Claude Desktop, Cursor, Claude Code, Windsurf and VS Code work with the disk through the gd_* tools
3. An S3-compatible API and a WebDAV endpoint: gd serve s3 for your projects, gd serve webdav to mount the pool on macOS and Linux without any FSD driver

Inside is the official rclone (downloaded automatically, verified by SHA-256). You never see or configure rclone.

Install: one command, then the wizard walks you through

irm https://raw.githubusercontent.com/yava-code/OnlyDrive/main/install/install.ps1 | iex

macOS/Linux:

curl -fsSL https://raw.githubusercontent.com/yava-code/OnlyDrive/main/install/macos.sh | bash

The installer downloads the exe, adds it to PATH and starts the wizard: engine, then Google account (browser, one click), then disks in Explorer, then MCP into your client, then autostart. Every step asks yes/no and explains what it does. The wizard also asks how many Google accounts you want to connect and repeats the sign-in flow for each one.

If there is no release yet, build from source and run the exe without arguments: go build -o gd.exe ./cmd/gd && gd. That starts the same wizard.

Manual commands (everything the wizard does)

gd setup        :: downloads rclone, installs WinFsp (1 UAC click), checks the environment
gd add          :: sign in to a Google account through the browser (OAuth, no keys)
gd daemon start :: background service
gd mount        :: the disk appears in Explorer
gd mcp install claude-desktop   :: or cursor / claude-code / windsurf / vscode
gd doctor       :: check that everything is OK
gd serve s3     :: (optional) S3 endpoint for projects
gd serve webdav :: (optional) WebDAV endpoint, mounts the pool on macOS/Linux
gd autostart on :: (optional) disks and daemon come up at login
gd ui           :: browser control panel (see below)

Browser control panel: gd ui

gd ui           :: panel on http://127.0.0.1:5590 (Ctrl+C to stop)
gd ui --port 8080
gd-ui.exe       :: same panel, opens the browser itself

The panel is a single local page, no external assets. It can:

• show each account with its quota, plus mount/unmount and remove buttons
• add another Google account (runs the same browser OAuth flow as gd add)
• start and stop the daemon and the S3 endpoint
• turn logon autostart on and off
• run gd doctor, with or without auto-fix

gd-ui.exe boot is the old fire-and-exit autostart mode: it raises the daemon, re-mounts the disks and exits. The current autostart target is gd-ui.exe tray: it does the same logon work and then stays resident as a notification-area icon.

Tray: autostart you can see and stop

With gd autostart on, logon launches gd-ui.exe tray (gd-ui must sit next to gd.exe; the installer downloads both). The entry is visible in Task Manager → Startup apps, where Windows lets you disable it without deleting anything. The tray icon itself offers:

• Open panel: the browser control panel
• Pause disks: unmount every drive and stop the daemon, so the connection stops using CPU, memory and network while you optimize the system; accounts and registrations are kept
• Resume disks: start the daemon and mount everything back
• Quit: end the resident process (the daemon keeps running if you paused it; use gd daemon stop or Pause for that)

The server binds to 127.0.0.1 only. To require an access token, set GD_UI_TOKEN before launching; clients then send it in the X-GD-Token header.

Commands

Command	What it does
gd	guided setup wizard (add multiple accounts, mount, MCP, autostart)
gd setup	download rclone + WinFsp, create config
gd add	add a Google account (browser, Allow)
gd accounts	list accounts
gd remove <acc>	remove an account
gd reauth <acc>|--all	re-authorize one account or all of them
gd oauth setup	guided walkthrough: create your own Google OAuth client, store it, re-authorize everything (see below)
gd oauth set|show|clear	store/inspect/remove the pair without the walkthrough
gd daemon start|stop|status	manage the background daemon
gd mount [acc|union] [--path <sub>]	mount as a disk (drive letter on Windows, ~/.gd/mnt/<account> on macOS/Linux; Linux needs fuse3/kio-fuse)
gd unmount [acc]	unmount
gd serve union	union remote over ALL accounts (one pool)
gd serve s3 [remote] [--port N]	S3-compatible API (see below)
gd serve webdav [remote] [--port N]	WebDAV endpoint over the pool; mount it on macOS/Linux with stock clients
gd serve status|stop	status/stop of both servers
gd autostart on|off	start daemon and disks at login
gd status	daemon, accounts, mounts
gd quota [acc]	used/total
gd share <path>	public link to a file
gd mcp	MCP server (stdio)
gd mcp install <client>	register MCP in a client
gd mcp prompt [file]	write an AGENTS.md for LLM agents
gd ui [--port N]	browser control panel
gd doctor [--fix]	diagnostics + auto-fix
gd update	update OnlyDrive itself (SHA-256-verified) and rclone

MCP tools

gd_accounts, gd_ls, gd_search, gd_read, gd_write, gd_mkdir, gd_move, gd_copy, gd_delete, gd_quota, gd_share, gd_mount_status

An agent with MCP access does not need a mount: every operation goes through the daemon API. Mount exists so you can see the disk in Explorer and work with it by hand.

Multiple accounts

Run gd add once per account, or let the wizard ask how many to connect. Each account becomes acc1, acc2, and so on, and all of them mount at once (letters are picked automatically). gd serve union folds every account into one storage pool: a file lands on the drive that has room. With a single account the pool repeats that one upstream, because rclone's union rejects a lone upstream.

WebDAV: mounting the pool on macOS and Linux

gd serve webdav            :: WebDAV on 127.0.0.1:9864 over the union pool

Then mount with the OS client:

# macOS
mkdir -p ~/pool && mount_webdav -S http://127.0.0.1:9864/ ~/pool
# Linux (davfs2)
sudo mount -t davfs http://127.0.0.1:9864/ /mnt/pool

Windows does not need this path: gd mount gives real drive letters through WinFsp. On macOS and Linux, gd mount acc1 uses the native path directly; WebDAV remains the way to mount the whole union pool as one directory. The CI runs a live mount round-trip on macOS and Linux on every push (macOS runners have Full Disk Access; Linux runners have /dev/fuse).

Versioning

The release version lives in exactly one place: internal/version (Number constant). A release bumps that constant and tags the same vX.Y.Z. Nothing else repeats the string: the panel footer is stamped from the constant when the page is served, and the landing page resolves the newest release tag from the GitHub API at view time (its static text says "latest" and needs no update).

Updating

gd update

Two steps, in order:

1. OnlyDrive itself. The newest GitHub release is resolved, the asset for your platform is downloaded and verified against the release's checksums.txt (SHA-256). A mismatch discards the download before anything is touched, and a magic-bytes check rejects HTML error pages even if a checksum ever matched. The old binary is kept as gd.exe.old next to the new one; a failed swap restores it.
2. The pinned rclone engine, same as before (its own published SHA256SUMS, daemon restart if it was running).

OnlyDrive updates land in the same release CI that publishes the landing page, so gd update and a fresh download always deliver the same bytes.

Autostart

gd autostart on first tries a scheduled task (schtasks). On machines where schtasks fails (a network-path error is the common case), it writes the per-user registry Run key HKCU\...\CurrentVersion\Run\gd instead and reports which method it used. gd autostart off removes both.

Run-key entries are visible in Task Manager → Startup apps, where Windows lets you disable an entry without deleting it.

Own Google client_id

rclone ships a shared, public Google Drive OAuth client, and rclone is retiring it during 2026. Until you store your own client, authorizing new accounts and refreshing tokens keeps working, but it will stop one day, so plan ahead. It is a one-time, five-minute chore per human, not per account:

gd oauth setup

opens the exact Google Cloud Console pages in order (project, Drive API, consent screen, credentials), stores the client_id/client_secret pair and re-authorizes every existing account automatically; each account is one browser Allow click. Prefer doing it by hand? Create an OAuth client of type Desktop app yourself and run:

gd oauth set <client_id> <client_secret>
gd reauth --all

A refresh token is bound to the client_id that minted it, so existing accounts must re-authorize once through the new client. gd oauth show reports which client is in effect (with the secret masked), gd oauth clear forgets the stored pair. In scripts and CI you can skip the storage entirely: GD_CLIENT_ID and GD_CLIENT_SECRET environment variables take priority over the stored pair.

One Console pitfall: after configuring the consent screen, press Publish app. Without publishing, the app stays in Testing mode, where Google expires refresh tokens after 7 days and caps you at 100 users. Publishing to Production without Google verification is fine for personal use: first-time authorizations show an "unverified app" warning that each account bypasses once with "Advanced -> Go to app", and the tokens then never expire.

With 10+ accounts or heavy automated uploads Google officially recommends your own client_id anyway (rclone documents it at https://rclone.org/drive/#making-your-own-client-id), and after 2026 it is simply required.

Limitations (important)

• Drive is not a block device: random writes go through a cache, so live databases (SQLite and friends) must not live on a mounted disk.
• Google upload limit: about 750 GB per day per account.
• ~/.gd/rclone.conf holds OAuth tokens. Never commit it or send it anywhere.
• rclone's shared Drive client_id is being retired during 2026. Bring your own OAuth client (see Own Google client_id) to keep authorizing past that date.

Config and data files

• ~/.gd/gd.json: gd state (accounts, mounts)
• ~/.gd/rclone.conf: OAuth tokens
• ~/.gd/rclone.log: daemon log; ~/.gd/serve-s3.log: S3 log
• ~/.gd/bin/: the rclone binary

Roadmap

• setup, accounts, mount (Windows), MCP, doctor
• S3-compatible server + union pool
• autostart at login, re-mount after reboot (schtasks + Run-key fallback)
• browser control panel (gd ui, gd-ui.exe)
• tray icon with Pause disks / Resume / Quit (Windows)
• gd serve webdav: mount the pool on macOS/Linux with stock WebDAV clients
• native mounting on macOS (rclone nfsmount, no macFUSE needed) and Linux (FUSE backend, no root): gd mount works on both, CI smoke round-trip on every push
• own Google client_id option (shared one retires in 2026)
• one-liner releases: scripts/release.sh vX.Y.Z

Releasing

One command, from a clean main:

scripts/release.sh v0.1.5

It refuses to run on a dirty or out-of-sync tree, refuses an existing or malformed tag, bumps the version constant (and fails on any stale version echoes left elsewhere), runs go build/vet/test, commits, tags, pushes, watches the CI run on the tag, verifies the published assets and the host binary's SHA-256, and patches the release notes if they are still the auto-generated changelog. --dry-run prints the plan and writes nothing. The tag equals internal/version.Number; goreleaser publishes from the tag in CI.

Tests

go test ./...
GD_LIVE=1 go test ./internal/rclone/ -run TestLiveRCProbe   :: live rclone rcd

License

Apache-2.0. The full text lives in LICENSE. Third-party pieces keep their own licenses: rclone (Apache-2.0, downloaded and managed by gd, never bundled), WinFsp (GPLv3 with an FLOSS exception, installed separately by the setup wizard) and the Go modules in go.mod.