[Feature]: [RFC] Extension System / Marketplace for custom integrations

[AriajSarkar]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

Not sure

Problem or use case

Currently, T3 Code provides a sleek, cohesive GUI for coding agents like Codex and Claude. However, as new AI models, native tools, and specialized developer workflows emerge rapidly, baking support for every single provider or tools directly into the core monolithic codebase will quickly become unsustainable. Users hav needs for custom context gatherers, local LLM providers (like Ollama or LM Studio), and specialized code execution sandbox.

Proposed solution

I propose introducing a formalized Extension/Plugin system that allows the community to build and distribute custom integrations without bloating the core T3 Code repo.

As a starting point (Phase 0), this would involve defining standardized extension points within packages/contracts, such as defining schema contracts for:

1. Custom LLM Providers (implementing the required JSON-RPC interfaces).
2. Custom tools or context providers.

In the future, this could evolve into local extension loading (via manifests) and eventually a community marketplace/registry, making T3 Code an extensible platform similar to VS Code.

Why this matters

This enables community growth, users can integrate their preferred obscure models or internal enterprise tools without requiring direct approval or maintenance from the core T3 Code team. It keeps the core app fast and reliable while offering massive flexibility to the community.

Smallest useful scope

Defining the TypeScript interfaces/schemas in packages/contracts for what a "Provider Extension" looks like, and adding a basic mechanism in apps/server to load a custom provider from a local path during session startup.

Alternatives considered

1. Native integration for everything (unsustainable overhead for maintainers, bloats the UI).
2. Hard-forking the repo for specific enterprise needs (fragments the community and makes upstream merges painful).

Risks or tradeoffs

• Security: Running third-party code in an app that controls agents with filesystem access is a significant attack surface. Proper sandboxing (e.g., using isolated contexts or strict IPC boundaries) will be deeply important.
• Maintenance: Designing a stable plugin API is difficult, especially when the core application is still in "VERY EARLY WIP" status and refactoring frequently.

Examples or references

• VS Code's extension architecture.
• Claude Desktop's MCP (Model Context Protocol).

Contribution

• I would be open to helping implement this.

[InterStella0]

This needs to be more talked about, i know a lot of you are just using LLM to post. But I dont wanna fork the project if i wanna add a new feature and potentially having to self maintain it. Community extensions really need to exist. I see a lot of possible features that can be added through this.

[gae-rafatjah]

This can be interesting. If i'm not wrong, the deepseek harness is a bunch of extensions and It can make testing and development easier too. It helps us to add our own features on top of the mainstream release without the need to patch them.

I do suggest a global and per project extension folder that the t3 loads and exposes it's functionality to allow us link and add custom extensions to it.

[rafaelhorvat]

I would see this become something like the extensions for VS Code... That would be optimal!

@t3dotgg any plans about this subject?...

[abhaymettu]

A declarative client half for the plugin work: styles and settings, no plugin code.

I saw "let us handle this" on #16047, so this is not a PR. It is a design note with running code, in case any of it is useful for the plugin system you are building.

Your runtime POC (spike/plugin-runtime-comparison) says the first public contribution types should be declarative. The client side of that, the gap artile describes on #6837, does not exist anywhere yet. It also needs no trust decision, so it can be small:

• A plugin is a folder in ~/.t3/userdata/plugins/ with a t3-plugin.json. The manifest uses your POC's fields (manifestVersion, namespaced id, version, apiVersion, contributes), decoded strictly, so a later entrypoints or capabilities field slots in without a format change.
• contributes.styles: CSS files. The server inlines url()s that point into the plugin's own folder as data: URLs and rejects @import and every other URL. The client gets inline style text, which is what the desktop CSP needs anyway.
• contributes.settings: boolean, select and range settings. Settings → Plugins renders them with the stock SettingsRow, Switch, Select and settings-slider. Values reach the CSS as --plugin-<id>--<key> (dots in the id become _) and data-plugin-<id>--<key> on <html>, and data-plugin-<id> marks an enabled plugin so its rules can scope to it.
• Enablement and values sit in ServerSettings.plugins (per environment, settings:write), so a paired phone or a guest link cannot turn a plugin on, and only enabled plugins' CSS crosses the wire.
• The server side is a copy of EnvironmentThemeService: a watched folder, guarded reads, and an opt-in environmentPluginsUpdated event on subscribeServerConfig. Clients that do not opt in see nothing. Mobile ignores it.

Worked examples: the background image from #6903 and "choose which thread details sections show" both become a folder with one stylesheet and a few settings, with no core code beyond two anchor attributes (data-thread-details-section, data-chat-layout). Because the signed app only reads data, users get these personal tweaks without building their own copy and losing signing and auto-update.

• RFC (goals, trust table, performance, API stability, alternatives): https://gist.github.com/abhaymettu/5e9df0174e968035dac33d8c78bcc992
• Branch (contracts, server service, settings page, docs, two examples, tests): https://github.com/abhaymettu/t3code/tree/feat/declarative-plugins (4 commits on main)
• Screenshots: in the same gist, two below.

Backdrop plugin on a thread	Settings → Plugins

Happy to open it as a PR, change its shape to fit your runtime, or leave it here as input.

Written with Claude Opus 5.5 (claude-opus-5-5) in Claude Code, running inside T3 Code.

[hunterbohm]

Is the plugin system still in progress on your side? I saw "let us handle this" on #16047 and the plugin-runtime branches from August, but nothing on them has moved since then.

Also, will the mobile app get plugins in the first version? It looks like mobile plugin commands were pushed back on those branches.

Happy to test early builds if that helps.

[johan-acevedo]

Concrete mobile use case for this RFC, from building t3-call (a voice-call companion for T3 threads):

We want a one-tap "call this thread" entry point from the mobile thread view — a thread-level action that opens https://<host>/v2?project=<id>&thread=<id>. Today there is no way for a third party to contribute one: the mobile thread menus are hard-coded (the v2 row menu is a fixed MenuAction[] with a fixed handleMenuAction switch; the thread-title menu in PR #21081 likewise only reuses built-in commands).

The smallest change that would unblock us is a narrow slice of this RFC: a contributed thread-level action defined as a URL template with {projectId}/{threadId}, surfaced in the existing thread row/title menus, on mobile from the start (mobile plugins were noted as deferred in this thread — this use case needs them in v1, since the phone is where the call happens).

Related pieces already in flight that we are deliberately not duplicating: Copy thread ID has since landed in the mobile v2 row menu (thank you — it unblocks manually building the URL); #21081 covers built-in title-menu actions; #30086 (t3-thread:// links no-op on mobile) and #21233 (URL-scheme allowlist) cover adjacent transports. None of them gives a third party its own one-tap thread action, which is the gap this comment is about.

Happy to test early builds; not proposing a PR, just adding the use case and the smallest scope that would help.