Twenty-seven OAuth service rows cover work and personal accounts
gogcli presents Google Workspace as a consistent command tree. Its generated OAuth table contains 27 service rows, including Gmail, Calendar, Drive, Docs, Sheets, Slides, Forms, Meet, YouTube, Analytics, and administrative APIs. Commands emit JSON for programs or stable TSV for shell work, while warnings stay on stderr. Account aliases reduce the chance that a personal-mail script runs against a work account.
Coverage varies by account type. Consumer accounts can use ordinary user services. Admin, Keep, and Cloud Identity Groups need a managed Workspace domain, with some paths requiring a service account and domain-wide delegation. AdSense and Photos Picker require explicit selection, while Photos Library access is limited to app-created media. The generated table records these differences instead of implying one token unlocks every command.
Six runtime controls can narrow an automation job
The README demonstrates --readonly, --no-input, exact command allowlists, Gmail no-send policy, dry-run plans, and wrapping for untrusted content. Read-only mode also restricts HTTP methods, so it can stop a mutation even when the command name looks harmless. JSON output and documented exit codes make failures observable without scraping terminal prose.
For long-lived agents, gogcli can bake policy into a separate binary. A profile can allow selected commands and lock flag values; blocked rules override allowed parents. The documentation still requires narrow OAuth scopes and account separation. A copied token may be used outside gogcli, so the 6 CLI controls do not replace a Google account created for the job.
What happened when we ran it
Our sandbox installed commit 29a5adf in 40 seconds and added 139 packages. The build succeeded in 91 seconds. The 13.4 MB repository held 2,306 files and about 317,503 lines of source. Six CI workflow files and a Dockerfile were present. No top-level tests directory was found, which is normal for Go projects that place _test.go files beside the packages they exercise.
The Go test run completed in 262 seconds with 84 passed and 0 failed. That is the cleanest measured result of these three repositories. It validates the checked-out code without proving every Google operation works against a live tenant. Our unprivileged sandbox had no secrets, while gogcli documents live API checks as an opt-in step.
Our starting image was golang:1.24-bookworm, yet the measured build completed. The checked-out module declares Go 1.26 and a newer preferred toolchain. Builders that disable automatic toolchain handling should install the declared version directly. The 91-second build and 262-second test result are repository measurements, not Google API latency figures.
OAuth testing status can create a 7-day token loop
The five-minute guide still requires Google Cloud setup. You choose a project, enable each API, configure consent, create a Desktop OAuth client, store its JSON, and authorize an account in a browser. The refresh token goes into the operating system keyring. A manual URL flow and encrypted file backend cover headless hosts.
External OAuth apps left in Testing issue refresh tokens for user-data scopes that expire after 7 days. Publishing the app as In production avoids weekly reauthorization for personal use, although sensitive scopes retain Google's warning and 100-user lifetime ceiling for an unverified app. Workspace administration adds delegated scopes, a service-account credential, and an impersonated user.
MCP writes stay hidden behind two explicit gates
gog mcp starts a typed stdio server rather than an unrestricted command runner. Read tools appear by default and can be narrowed with --allow-tool. A write tool needs both --allow-write and a matching selector before it appears. Per-account policy can set a lower ceiling, while runtime flags may narrow it again.
The server still has the authority of its selected Google account. The MCP guide recommends tool selectors plus exact command allowlists and read-only mode where possible. Before connecting an agent, list the tools and run a read against the intended account. If writes are necessary, authorize 1 named operation and inspect dry-run output before widening access.
Version 0.39.1 retains workflow-specific gaps
Open issue 1097 reports a Slides limitation from v0.39.0: one 7-slide rebuild needed 197 separate writes because Slides lacked the Docs batch facility. Issue 1098 says paragraph alignment, spacing, and indentation were unreachable through Slides commands. These advanced cases matter if gogcli is meant to be the only API layer for native deck production.
Gmail has a smaller edge. Issue 1058 reports that a plain-text draft made in v0.38.1 looked correct in Gmail's editor, then gained fixed line breaks after a person sent it from the web UI. The HTML workaround avoided the problem. These reports argue for testing the full human workflow, not assuming a successful API response settles formatting.
A September 8 push sits beside 9 issues and PRs
GitHub recorded 8,392 stars, 9 open issues and pull requests, and a last push on September 8, 2026. Release v0.39.1 arrived on September 5 with pagination-cycle protections, Google API dependency updates, and MCP SDK 1.0. The small queue includes detailed Slides and Gmail reports. Recent code, releases, and issue investigation support a high community score.
The measured result is persuasive: all 84 tests passed after a 40-second install and 91-second build. OAuth consent, token storage, service scopes, and write policy decide whether gogcli is a safe convenience or an overpowered cron credential. It fits teams willing to do that policy work once and reuse one observable CLI across several Google services.