Extending Goose: Making the GRC More Modular

^{Originally posted by **Abhijay007** June 29, 2026}
While working on #9341 and discussing it with @michaelneale, @lifeizhou-ap and others, I started thinking more about the long-term direction of the Goose reference client.

One thing that became clear is that we probably don't want every new feature, UI component, or integration to live directly inside the reference client. As Goose grows, there will be many different use cases, organizations, and products built on top of it, all with different requirements. Trying to support every workflow in core would eventually make the reference client increasingly complex.

That made me wonder whether the reference client should instead provide a modular extension system, where developers can extend the UI and functionality through plugins rather than maintaining entirely separate clients.

## The Idea

The reference client (GRC) would remain a lightweight foundation, exposing well-defined extension points that plugins can hook into.

Rather than modifying the application itself, plugins/integrations/extensions could extend the experience by contributing things like:

- New navigation pages
- Sidebars or sidecars
- Chat actions
- Custom renderers
- Message decorations
- Settings pages
- Integrations
- Notifications or dashboard widgets
- Other UI components

The goal wouldn't be to replace existing functionality, but to augment it.

This feels similar to how many successful platforms expose extension points while keeping the core application small and stable.

## Why This Seems Valuable considering other aspects

One motivation came from thinking about integrations.

Many integrations (Gmail, Google Calendar, Slack, GitHub, Linear, Notion, internal tools, etc.) require much more than simply exposing an MCP or calling an API.

They often need things like:

- OAuth/account linking
- Token management
- User preferences
- Permission management
- Settings UI
- Notifications
- A trusted place for users to review or revoke access

An MCP can provide the capability, but it doesn't solve the product experience around authentication, configuration, and user interaction.

Without a shared extension model, each serious integration may eventually need to build its own setup flow or mini-client.

A plugin architecture could instead allow Goose Desktop (or another reference client) to become the common configuration and control surface, while the plugin provides the actual functionality.

## Plugin Distribution

If plugins become first-class, it would also be nice if they could be distributed independently of Goose releases.

Similar to Recipes and Extensions today, we could eventually have a plugin catalog where users can discover and install functionality as needed.

Organizations could also maintain their own internal plugins without needing to fork or modify the reference client.

## Design Goals

Some properties that feel important:

- this should only augment functionality, not replace core behavior.
- those functionality failures should never prevent Goose from loading.
- these integrations should be installable independently of the application.
- it should ideally be dynamically loaded and unloaded.
- The extension API should be stable and well documented.
- The reference client should stay lightweight regardless of how many plugins exist.

@michaelneale shared a more detailed design document covering this idea, including potential extension points, their expected behavior, and how it could work in practice: https://docs.google.com/document/d/1aU9J30fPuroPVihGd5fo-N1z5qUvt2GDSpNszJFMk-4/edit?pli=1&tab=t.0

## Longer-Term Thought

One aspect that feels especially interesting in an agent-first ecosystem is plugin development itself.

Rather than writing extensions entirely by hand, Goose could understand its own extension API, explain available extension points, and even help generate or iterate on plugins through conversation.

That feels like a natural direction for an AI-native platform.

## Open Questions

I'm mostly curious whether this aligns with the team's vision.

- Should the reference client remain intentionally lightweight?
- Does a plugin architecture make sense for extending the reference client?
- Would it be preferable to encourage plugins instead of adding every new feature directly into core?
- Are there architectural constraints that would make this difficult?

I'd love to hear everyone's thoughts.

---

## Related Context

- PR: #9341

Previous discussions :
- https://discord.com/channels/1287729918100246654/1408153538537721966/1516697049578602606
- https://discord.com/channels/1287729918100246654/1408153538537721966/1516833084086030487
- https://discord.com/channels/1287729918100246654/1516843943591940116/1516894211448766504

Initial design proposal (link) by @michaelneale

- https://docs.google.com/document/d/1aU9J30fPuroPVihGd5fo-N1z5qUvt2GDSpNszJFMk-4/edit?pli=1&tab=t.0