Developer Fired by Google for Building Google Workspace CLI

Two months ago, Justin Poehnelt was fired by Google. His offense: creating a CLI tool for Google Workspace that went viral, hit #1 on Hacker News, accumulated thousands of GitHub stars, and attracted many thousands of users in just a couple of days.

The timing made it worse. Two days before his termination, Google announced at Cloud Next 2026 that an official Workspace CLI was in development.

What Happened

Poehnelt spent nearly seven years on Google's Workspace Developer Relations team. His job involved building open-source layers and abstractions over Google APIs - exactly the kind of work the team was designed to do. The CLI tool he created, gws, provides unified command-line access to Google Drive, Gmail, Calendar, and other Workspace APIs.

When the tool went viral, it caught leadership by surprise. Directors and leaders asked what they could learn from the project. Then legal started grilling him about why Google's logo and brand colors appeared on a Google Workspace GitHub code repository.

According to Poehnelt, the core issue was fear of disruption - not about his CLI specifically, but about what AI agents meant for Workspace as a product. The CLI made Workspace APIs accessible in a way that AI coding assistants and automation tools could easily consume.

What HN is Saying

The Hacker News thread has 340+ comments and surfaces several angles on the story.

The process question dominates. Multiple former Googlers confirm that Google has strict OSS release processes. The debate is whether Poehnelt followed them. He claims the process is "not clearly documented and always changing" and that he had approval through the internal launch system (Ariane/Launcher2) with the engineering bit flipped by his manager. Others point to Google's public OSS release documentation as evidence the rules were clear.

The branding issue is murky. The GitHub organization googleworkspace displays Google's logo on all its repositories - that's an org-level setting, not something Poehnelt added. The README includes the standard "This is not an officially supported Google product" disclaimer. But releasing a viral product with official-looking branding without the full corporate launch review is risky at any large company.

20% time is invoked nostalgically. Several commenters see this as evidence that Google's famous 20% time culture is dead. "Google has gone from encouraging 20% time to firing people for doing it," writes one commenter. Others push back: 20% time never meant bypassing launch approvals, and this appears to be less about side projects and more about proper channels.

The AI disruption angle resonates. The CLI made Google Workspace APIs trivially accessible to AI agents. One commenter notes: "Your tool is something that made Workspace so much more useful to me personally... Getting fired for making a product more useful to customers is quite ironic." Another adds that paired with a Claude skill, it saved significant time creating meeting notes - exactly the kind of AI-native workflow that Workspace apparently wasn't ready to officially support.

Corporate politics gets blamed. "Good ideas are now risky because it steps on the toes of someone's fiefdom," writes one commenter. Another: "They've been GE'd." The general sentiment is that something broke in how Google handles internal innovation.

Read the full discussion at Hacker News.

The Bigger Picture

This situation illustrates a recurring tension in big tech: the gap between what developer relations teams are supposed to do (build tools that make platforms accessible) and what product teams want to control (the timing, branding, and narrative around new capabilities).

It also highlights how AI is changing developer tools. A CLI that exposes APIs cleanly isn't just a convenience anymore - it's infrastructure for AI agents. When every developer has access to coding assistants that can call arbitrary APIs, making those APIs easily callable becomes a strategic decision.

For developers working at large companies, the lessons are practical:

Document your approvals. If you have sign-off, make sure it's on record and that you understand exactly what scope it covers.

Understand branding implications. Using company GitHub orgs, logos, or anything that could make your project look official creates liability. Even "not officially supported" disclaimers may not be enough if the visual presentation suggests otherwise.

Consider timing. A project that goes viral right before your company announces a competing official version creates an awkward situation for everyone - especially if your project is better received.

Recognize disruption risk. If your side project enables use cases that threaten existing business models (like AI agents automating away SaaS seats), expect friction from stakeholders who see the threat before they see the opportunity.

The Tool Itself

The Google Workspace CLI (gws) is still available at github.com/googleworkspace/cli. It provides command-line access to Workspace APIs in a format that works well with AI coding tools. Whether Google eventually releases their own version or claims this one remains unclear.

For now, it serves as a case study in what happens when developer tools become too useful too fast.

Sources

• Justin Poehnelt's X post
• HN Discussion (340+ comments)
• Google OSS Release Documentation
• Google Workspace CLI Repository