Extension system: broad, VS Code-like extensibility for T3 Code

[ztomas-codes]

Problem

T3 Code covers a growing range of coding workflows, but users and teams will always need integrations and UI that the core app does not ship. Maintaining a fork for each customization makes updates harder, while adding every integration to core increases the maintenance burden for everyone.

I'd like a first-class Extension system, with the breadth and everyday experience of extensions in VS Code. The ambition is to make substantial features possible outside the core repository, including features maintainers have never anticipated.

What extensions should be able to contribute

• Commands and actions: command-palette entries, configurable shortcuts, context-menu actions, project and thread actions, and contextual toolbar controls.
• UI: sidebar views, custom panels and tabs, settings pages, status indicators, thread-detail sections, and custom editors or viewers for files and artifacts. Extensions should be able to build interactive interfaces rather than being limited to a few predefined buttons.
• Chat and composer: composer actions, prompt templates, skills, attachment and context sources, structured message renderers, and interactive tool-result views. Reading conversation content or intercepting a submission should require an explicit permission and visible user control.
• Agents and tools: provider adapters, model integrations, MCP tools and resources, and reusable agent workflows. An extension should be able to expose the same capability to a person through the UI and to an agent through a tool.
• Workspace integrations: source-control and hosting integrations, issue trackers, CI systems, deployment services, terminals, project scripts, diagnostics, and additional language or repository tooling.
• Appearance: themes, icon themes, and documented styling tokens for extension-owned UI.
• Lifecycle and automation: supported events for project and thread creation, turn completion, checkpoint creation, and relevant workspace changes, plus actions usable by scheduled tasks.

For example, a GitLab extension could add a merge-request panel, pipeline status, palette commands, and agent tools. A deployment extension could add a project action, show deployment logs, and expose a tool the agent can use when asked to deploy. Neither should require patching the main app.

A VS Code-like extension experience

I would want the whole extension workflow, not only an internal plugin loader:

• An extension gallery for discovery, search, installation, updates and removal, with publisher identity, documentation, changelogs and declared permissions.
• An open package format and manifest declaring contributions, activation conditions, API compatibility, dependencies, configuration and required capabilities.
• Installation from a local package or a private registry as well as the public gallery. Teams should be able to distribute internal extensions without publishing them publicly.
• Enable/disable controls globally, per project and per machine, with portable extension profiles or recommendations for a repository.
• A TypeScript SDK, useful API documentation, example extensions, a development host with fast reload, logs, debugging and packaging tools.
• Versioned public APIs and a clear compatibility policy so extension authors can support app updates without depending on private implementation details.

The reference is VS Code's extensibility model and developer experience. Compatibility with relevant existing VS Code extension APIs would be worth exploring, but this proposal does not assume arbitrary existing VSIX packages can already run unchanged.

Remote environments and clients

The extension model should account for T3 Code's architecture from the beginning:

• A client part contributes UI on the device where I am using T3 Code.
• An environment part runs next to the workspace, filesystem, credentials and provider processes on the selected machine.
• One extension can contain both parts, communicating through a documented, typed bridge. A UI action should run against its selected destination environment, including over a relay or tunnel.
• Desktop, hosted web, locally served web and mobile should have a clear support model. Shared commands, tools and environment-side functionality should remain usable across clients; richer UI contributions can declare which clients they support and supply an alternative where necessary.
• Installing an extension locally should not silently install or execute it on every connected machine. The app should make its installation location and execution location clear.

Keep the host dependable

Broad extensibility needs boundaries that preserve the app's performance and reliability. I'd like an isolated extension host, lazy activation, scoped subscriptions, cancellation, resource diagnostics, and a way to disable a broken extension without losing access to the app. Extensions should clean up their views and subscriptions when deactivated.

Permissions should cover filesystem access, terminal execution, network access, conversation content and secret-provider access. Credentials should use supported secret APIs rather than being copied into extension settings. Extension operations should go through public services and respect environment grants, rather than modifying the database or replacing orchestration internals.

Direction to discuss

Would maintainers support an extension platform with this breadth as a long-term direction? Which contribution points would make a useful first release while leaving room for the wider system?

This is a product proposal requesting discussion and approval of direction. It is not an implementation PR. A first release could start with commands, panels, settings and environment-side tools, but I would want the API and packaging model designed to grow beyond that initial set.

Related: browser-extension support #13979 covers extensions inside the integrated browser. This proposal concerns extending T3 Code itself.

Prepared with GPT-6.1 Sol through the Codex harness in T3 Code.