Fired Over the Workspace CLI Google Then Shipped

A 7-year Google veteran builds an open-source CLI for Google Workspace, it rockets to #1 on Hacker News and pulls in thousands of GitHub stars, and weeks later he's out the door. Justin Poehnelt's account of his firing went viral for obvious reasons: it reads as a corporation punishing exactly the kind of initiative every leadership deck claims to want. levelsio publicly told Sundar Pichai to rehire and promote him. Peter Steinberger's take was blunter: Google fired the guy who made the Google Workspace CLI because he made the Google Workspace CLI.

It's a great story. It's also a Rorschach test, and most people are reading the inkblot they already wanted to see. The more useful read is that this single project tripped three separate wires at once: trademark, security, and strategy. Any one of those is a serious conversation at a company Google's size. All three together explain the outcome far better than "leadership feared disruption," which is the part everyone is quoting and the part that's hardest to verify. Worth stating up front: nearly everything about the firing itself comes from Poehnelt's own posts. The tool, though, is very real and very public, and that's where the interesting engineering actually lives.

What the tool actually is

Strip away the drama and gws is a genuinely sharp piece of design. The Google Workspace CLI that now lives under the googleworkspace org doesn't ship a hardcoded list of subcommands. It reads Google's own Discovery Service at runtime and builds its entire command surface dynamically. Add an API method to Drive or Gmail upstream, and the CLI picks it up with no new release. That's the opposite of how most vendor CLIs work. The community CLI for Microsoft 365, currently around v11.7.0, ships a static, hand-maintained command set across SharePoint, Teams and Entra. Mature, predictable, and perpetually chasing the API surface. gws sidesteps that maintenance treadmill entirely by generating itself.

The other half of the design is that it's built for agents, not just humans. Written in Rust, Apache 2.0 licensed, every response comes back as structured JSON with --dry-run to preview requests and auto-pagination via --page-all. It bundles dozens of agent skills as SKILL.md files and exposes an MCP server so Claude Code or Gemini CLI can drive Workspace directly:

npm install -g @googleworkspace/cli
gws auth setup
gws auth login
gws drive files list --params '{"pageSize": 10}' --page-all | jq -r '.files[].name'

This is the "agent-native CLI" pattern crystallizing in real time: a thin, introspectable, JSON-first wrapper that turns a sprawling REST surface into something an LLM can actually plan against. People praised exactly that on Hacker News, with one commenter noting companies are finally putting proper interfaces in front of things that should have had them years ago.

Why a Workspace CLI is strategically radioactive

Here's the part that makes this more than an HR anecdote. Workspace is a per-seat business. The value a customer pays for is substantially the GUI and the lock-in around it. The moment an agent can read, triage, draft and send mail, build a spreadsheet, and post to Chat through one clean command surface, the seat starts to look less like a product and more like an API key. That's the SaaS-disruption thesis everyone's been circling for two years, and a polished, agent-ready CLI is about the most concrete embodiment of it you could ship.

Poehnelt's own framing is that the fear "wasn't specific to my CLI, it was a broader fear in what agents meant for Workspace." Believe that or don't, but the structural tension is real. And the timing he describes drips with irony: an official Workspace CLI was announced at Google Cloud Next two days before he was let go, and an official version later showed up under the company's own org. When someone asked whether the official tool differed from what he shipped, his reply was a shrug: "there is now. let's just say there wasn't much interest in CLI's earlier in 2026." The exact lineage between his original project (reported to have been a Go tool called gog) and the Rust-based gws that's now public is genuinely unclear from what's available, and the dates in the public record don't line up cleanly. Treat that thread as his side of a story Google hasn't told.

Advertisement

Shadow GPS — know where it is, always Real-time GPS tracking for vehicles, gear and loved ones. No monthly contracts.

The part the hot takes skip

Now the unglamorous mechanics. At basically every large tech employer, your invention-assignment agreement means work related to the business is owned by the company, full stop. Google in particular runs a famously strict open-source release process: internal review, license checks, security sign-off before anything goes public under the company's name. Poehnelt has said his job on Workspace DevRel was literally to "create open source layers and abstractions over APIs." Fine. But there's a wide gap between an approved DevRel abstraction and a viral public release carrying the Google logo and brand colors, which by his own account got him "grilled by legal." Trademark governance isn't optional flair. An unauthorized release wearing the company's marks is the kind of thing legal escalates on reflex.

Then there's security, and this one's underrated. A tool that brokers OAuth access to all of Workspace is a serious surface. The repo itself warns that the recommended scope preset includes 85-plus scopes and will fail for unverified apps, while testing mode caps consent at roughly 25 scopes. One Hacker News user reported burning 45 minutes on the default setup flow before hitting scope and verification errors. Credentials are encrypted at rest with AES-256-GCM and stored in the OS keyring, which is the right call, but the point stands: shipping a public, brand-stamped client that requests sweeping access to customer mail and files without security review is exactly what review processes exist to catch. As one skeptical reply put it, you built an OSS tool for a proprietary product owned by your employer without their approval and didn't expect friction?

So the honest read isn't "Google fired a hero for innovating." It's that a strategically sensitive tool shipped publicly, under company branding, touching a huge OAuth surface, apparently outside the normal sign-off path. The strategy angle is the spicy one, but the trademark and security violations are the boring, defensible ones.

What this means for you

Two takeaways, one career and one practical.

The career one is concrete, not preachy. Before you open-source anything adjacent to what your employer does, read your IP assignment and OSS-contribution policy, and route it through whatever review exists. The friction is annoying and it's also the thing that keeps your side project from becoming a termination. Never put your employer's logo, name or brand colors on a repo you haven't cleared. That's not bureaucratic theater, it's the single fastest way to turn an engineering question into a legal one. And understand the difference in your org's eyes between an internal tool, an approved abstraction, and a public launch that goes viral. Those are three different risk categories even when the code is identical.

The practical one: gws itself is worth a look right now, with caveats. If you're wiring an LLM agent into Gmail or Drive, the structured-JSON-plus-MCP design is a real shortcut over hand-rolling REST calls and OAuth plumbing, and the dynamic Discovery Service generation means it won't rot as the APIs move. But it's pre-1.0 (npm sits around 0.22.5), the README explicitly promises breaking changes on the way to v1.0, and it still carries the "not an officially supported Google product" note despite living under the official org. The auth setup is fiddly enough that you should budget real time for the scope dance, especially on consumer @gmail.com accounts. For a personal workflow or an internal automation, that trade is fine. For anything load-bearing in production, pin your version and watch the changelog.

The genuinely interesting thing here isn't the firing. It's that the most disruptive interface to a per-seat SaaS giant turned out to be a few hundred lines of Rust that regenerates itself from a discovery doc. Whoever ends up owning that pattern, the pattern isn't going back in the box.