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.

[pouyarezvani]

+1 for plugins. A large share of the layout requests in Ideas are personal preferences that the team should not have to ship as settings one by one, and a plugin system would let people handle them without maintaining a fork.

If a small first slice would help, user stylesheets may be the smallest useful one: a folder of .css files that you switch on in Settings → Appearance and that load after the theme, similar to Obsidian's CSS snippets. It needs no plugin API, and it covers most visual preferences, such as a different color for the right panel (#32131) or keeping the current flat design (#32130).

Snippets would also survive updates far better if the main areas of the window had stable attributes, for example data-region="sidebar", "chat", "right-panel" and "composer", which the team could treat as a public surface while everything else stays internal.

[vulonviing]

Thanks for sharing this. I ran into the same missing piece from the other side, and what I found along the way may be useful for the plugin design, whether you build on this branch or on your own system.

I wanted multi-model workflows in T3 (several models answer independently, review each other over rounds, then one result is written back to the main chat) without maintaining a fork. With no extension API, I ended up patching the installed app bundle and keeping the feature code in a separate add-on: https://github.com/vulonviing/t3-code-addons

Building it surfaced a few host-side problems that any plugin doing orchestration will probably hit:

• Resume without repeating work. If the app restarts mid-run, a plugin needs durable per-run state and idempotent resume, or it re-sends paid model turns. I store each round as a frozen packet so a resumed run continues from the last completed step.
• Partial failure, cancellation and timeouts. One child session failing or hanging must not block the rest, and cancelling must clean up child sessions. This needs explicit settlement and cleanup recovery after a crash.
• Busy parent threads. Writing a result back is unsafe if the parent chat is mid-turn, so a plugin needs a way to defer or queue the write.
• Per-session model and effort settings. Different sessions in one run need different models and reasoning effort, and the effort option names differ per provider.
• Compatibility checks. I verify the host version and file hashes before applying anything, and refuse unsupported versions. A plugin loader could do the equivalent with a declared host-version range.

The bundle patching also costs something real: the app has to be re-signed locally, which can affect distributor-bound features, and every official update needs the patch checked again. That is the main reason I'd like to see a supported extension surface.

I haven't tried my code on your fork, so I can't say which of these your SDK already covers. Either way, I hope the list above is useful input.