Plugins: a working build to try before you settle the design

[ashx-j]

Hey @t3dotgg, @juliusmarminge and @maria-rcks, it's ash. I've been working on this plugin system for the past few days in hopes that I can at least speed up the process of getting plugins into T3 Code. There are a few things I'd like to change about T3, but I don't want to commit to maintaining my own fork, and I'm sure others feel the same way. I know earlier PRs that tried to build plugins were closed, and I started this fully aware of that. I'm happy to make any changes you ask for, even substantial ones. I just want to see plugins in T3 Code.

Everything below was written by my agent. Thank you for reading :)

---

The plugin system is in a fork you can build and try before you settle on a design. It needs 2 decisions from you:

1. Should plugins be trusted code that runs in the server process and the page, like VS Code and Obsidian extensions? These are. Nothing is sandboxed, and the permissions a manifest lists are shown to the user but not enforced.
2. Would you take the first slice below as a PR, or would you rather build plugins yourselves and use this as a reference?

#8014 was closed because it set up a large plugin contract in one branch, so this isn't a request to merge the whole branch. If you build your own, the internals doc lists the problems this build hit and how it solved them. If you'd take contributions, the split below keeps each PR to one part.

Try it

• A draft PR with the full diff and screenshots, from the branch feat/plugins-polish
• User guide, internals and the SDK README
• 8 example plugins, including the composer row from before the redesign, a thread digest and a full theme
• A test theme that installs from git (https://github.com/ashx-j/test-t3-overhaul) or npm (test-t3-overhaul)

What a plugin can do

A plugin is a folder with a t3-plugin.json manifest, an optional server entry and an optional web bundle, typed by a new @t3tools/plugin-sdk package. Users drop the folder on Settings → Plugins, or install from a git URL or an npm package. Updates for git and npm plugins show in the sidebar's update button.

• Themes and CSS. The boot screen and the desktop window open in the theme's colors.
• New UI: composer buttons and banners, slash commands, @ items, thread header buttons and menu items, sidebar badges, message actions, code block renderers, right panels, full pages, a sidebar section, command palette entries, and desktop menu, tray and global shortcut items.
• Redraw 7 parts of the app from T3's own controls: the composer's control row, user and assistant messages, tool steps, the diff view, the sidebar and the Settings page frame. The plugin places T3's controls instead of copying them, so it keeps working when a control changes.
• Change, replace or block a message before it's sent, answer approval requests, run code after each turn, add notes to threads, and handle slash commands on the server that reply without starting a turn.
• Give agents instructions, skills (Claude and Codex) and MCP tools.
• Change the thread titles, commit messages, PR text and branch names T3 generates.
• Add providers, as ACP agents or full drivers, and source control hosts.
• Settings from a JSON Schema, including secrets, plus storage, HTTP routes and scheduled jobs.

How it handles performance, remotes and surfaces

• With no plugins installed, the web loader never downloads. It's its own chunk, fetched only when an active plugin has a web part. Plugin registries sit behind atoms that never change without plugins, so no thread or sidebar row re-renders because of them.
• Orchestration stays pure. Message hooks run in the dispatch path before a command reaches the orchestrator, with a 2-second deadline each, and a hook that fails lets the message through. Orchestrator.ts gains 2 internal commands, for plugin notes and slash command replies.
• Each environment has its own plugins. With all environments selected, Settings → Plugins installs on each one. Web bundles load with the connection's credentials, so they work over T3 Connect. Plugin UI comes from the main environment only.
• It covers web and desktop. The mobile app shows no plugin UI, because release builds can't load code.
• Plugin state lives in its own files (plugins.json, plugins.sqlite), so it adds no migration to statev2.sqlite and no key to settings.json.
• A plugin that throws or hangs is marked failed on its row and never stops the server.

Proposed split

The branch adds about 24,700 lines in 176 new files and about 5,100 lines to 173 existing files. About 7,300 of those lines are tests. Each PR below works on its own:

1. The plugin host and Settings → Plugins: manifests, local folder installs, enable, disable and reload, settings, storage and server entries.
2. The web loader, themes and CSS.
3. New UI: buttons, menus, panels, pages and command palette entries.
4. Message and turn hooks.
5. Agent instructions, skills and MCP tools, plus tools that let agents manage plugins, off by default.
6. Installs and updates from git and npm.
7. Redrawing T3's parts.
8. Provider drivers and source control hosts.
9. Desktop menu, tray and global shortcuts.

Earlier proposals: #6714, #6837, #23574 and #31141. saphid's open stack, starting at #16048, covers some of the same ground with a different design.

Claude Opus 5.5 wrote the code in T3 Code, and ash directed and tested it.