gogcli: A Read-Only-by-Default Terminal Client for Google Workspace

What gogcli Solves and Who It Is For

gogcli, distributed as the command gog, is a single binary that talks to Gmail, Calendar, Drive, Docs, Sheets, Slides, Forms, Contacts, Tasks, Meet, Chat, and more. The README describes it as 'one command-line client' for the Google Workspace surface. It targets people who want to avoid clicking through web interfaces, scripts that need machine-readable output, CI pipelines, and agents that must operate with explicit account routing and safety controls. The core value is not just breadth of API coverage, but the safety layer: a runtime read-only flag, command allow/deny rules, a Gmail no-send policy, untrusted-content wrapping, dry-run plans, and safety-profile binaries with baked-in policy. This makes it a fit for organizations that want to let an LLM agent touch Workspace data without granting unfettered write access.

Safety Mechanisms: More Than a Read-Only Flag

The safety story is layered. The global --readonly flag is the first gate; it appears in the quick-start examples like gog --readonly gmail search. But there are finer controls. The README shows --enable-commands-exact gmail.search,gmail.get, which restricts execution to an exact allowlist of commands. --gmail-no-send blocks any send operation at the Gmail level. --no-input disables interactive prompts, and --wrap-untrusted wraps output that might contain untrusted content. Dry-run plans let you preview actions before they execute. Safety profiles go further: they produce binaries with command policy and locked flag values baked in at build time, so a deployed agent cannot override them at runtime. This is a meaningful design choice: instead of relying on the agent to behave, the binary itself is compiled with constraints. That is a stronger boundary than a config file that an agent could edit.

Typed MCP Server: No Shell Bridge

The gog mcp command exposes a typed stdio MCP server. The README emphasizes that it does not provide a generic shell or command bridge. That means an agent using MCP cannot just run arbitrary shell commands through gog; it can only invoke the typed tools that gog exposes. The server is read-only by default, and writes require explicit command and tool authorization. This is a deliberate departure from MCP servers that wrap a shell and let the model call exec. For agent deployments, this is a safer pattern because the tool surface is finite and declared. The trade-off is that any new Google API action must be implemented as a gog command and exposed as a tool; you cannot improvise a new operation on the fly.

Installation and the Module Path Gotcha

Installation is straightforward via Homebrew: brew install openclaw/tap/gogcli. With Go, the README gives go install github.com/openclaw/gogcli/cmd/gog@latest. But there is a caveat. The module path moved from github.com/steipete/gogcli to github.com/openclaw/gogcli. Until the first release after that move is tagged, @latest still selects an older tag that declares the previous path and fails. The README suggests installing a specific version from the old path, like go install github.com/steipete/gogcli/cmd/gog@v0.34.2, in the meantime. This is a real friction point for anyone who expects @latest to just work. The Homebrew path likely avoids this because the tap points to a specific release, but the Go install route needs care.

Authentication and Multi-Account Routing

gog supports multiple authentication methods: Desktop OAuth clients, direct access tokens, Application Default Credentials, and Workspace service accounts. The quick start shows creating a Desktop OAuth client in a Google Cloud project, downloading the JSON, and running gog auth credentials set. Then you add an account with gog auth add you@gmail.com --services gmail,calendar,drive. Account routing is explicit: you can set GOG_ACCOUNT as an environment variable or use --account work with an alias defined by gog auth alias set. Tokens are stored in the platform keyring by default, with an encrypted file backend for headless systems. This multi-account support is useful for people who manage personal and work Workspace accounts from one machine. The README also notes that some services, like Admin Directory and domain-wide delegation, require a managed Workspace domain, so consumer accounts cannot use the full surface.

Output Contracts and Scripting

For scripting, gog offers --json for structured output and --plain for stable TSV. Prompts, progress, and warnings go to stderr, which keeps stdout clean for parsing. The --no-input flag ensures commands do not hang waiting for user input in CI. The README also mentions that the binary generates its command schema, reference pages, and agent skills from the same command tree via gog schema --json and gog schema gmail search --json. That means the documentation and any agent-facing skill definitions stay in sync with the actual command implementation. This is a good design for maintainability, because there is no separate hand-written spec to drift.

Limitations and Wrong-Tool Cases

The most obvious limitation is the module path issue, which can break go install for new users. Another is the OAuth scope default: the gmail service lists scopes like gmail.modify, which includes modify permissions, not just read. The README shows how to narrow it with --gmail-scope send or read-send, but if you do not specify, you get the broader scope. That is a safety concern for agents. Also, the MCP server is read-only by default, but enabling writes requires explicit authorization, which is a configuration burden. If you only need to read Gmail and never send, a simpler tool like mutt with IMAP might be lighter. gogcli is the wrong tool if you want a minimal footprint or if you cannot use a Go binary in your environment. The breadth of services also means the binary is likely large, though the README does not give a size.

Alternatives: What Else Exists

The most direct alternative is Google's own gcloud CLI, which can authenticate and call APIs but is not designed for Workspace end-user operations like reading mail or calendar events. For Gmail specifically, you might use curl with the Gmail API directly, but that requires handling OAuth yourself. Another alternative is the Python-based google-api-python-client, which gives full control but requires writing code and managing scopes manually. The key difference is that gogcli provides a pre-built command surface with safety flags baked in, whereas the alternatives are lower-level. For agent use, an MCP server built on google-api-python-client would need you to define the tools and safety boundaries yourself. gogcli's advantage is that the safety profile is compiled into the binary, not left to the agent's discretion.

Maintenance and License

The repository is under the MIT license, which is permissive and allows commercial use with attribution. The last push was August 2026, and there are recent releases including v0.38.1, so the project is actively maintained. The README references generated documentation and a command index, which suggests a disciplined release process. The module path move is a maintenance event that could cause confusion for existing users, but the README addresses it directly. For upgrades, you should watch release notes for changes to command behavior or safety defaults. The MIT license means you can vendor the binary or modify it, but you are responsible for understanding the OAuth consent screen and API enablement, which the quickstart covers.

Editorial conclusion

Adopt gogcli if you need a scriptable, multi-account terminal client for Google Workspace and value explicit safety boundaries like --readonly, --gmail-no-send, and baked safety profiles. Skip it if you only need one API and prefer a single-purpose tool. Before adopting, verify the module path situation: the move from github.com/steipete/gogcli to github.com/openclaw/gogcli means go install @latest may still select a broken old tag; pin a specific version from the correct path. Also confirm the OAuth scopes you request match your actual needs, since the default gmail scope includes modify permissions.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes