[Feature]: Pi-style extension API for lifecycle hooks, UI contributions, and settings

[Jules-Astier]

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

packages/contracts or packages/shared

Problem or use case

I would like to make T3 Code extensible in a similar spirit to the Pi agent: extensions should be able to react to application and agent lifecycle events, expose their own settings, and contribute small pieces of UI without requiring every integration to be added to T3 Code itself.

A concrete example is an extension that reacts when a user-visible turn settles, performs a user-configured integration, exposes its configuration under Settings, and adds a status indicator or action to the thread UI. Today this requires modifying T3 Code and maintaining a fork.

There are related issues, but they cover separate parts of this problem:

• [Feature]: [RFC] Extension System / Marketplace for custom integrations #1582 focuses primarily on provider/tool extensions and a possible marketplace.
• Feature request: local lifecycle hooks / notification integration for tools like peon-ping #376 focuses on local lifecycle notifications.
• [Feature]: Internal panel host for first-party panel composition #1377 proposes an internal-only panel host and explicitly excludes an external plugin API.

What is missing is one small, coherent extension boundary connecting lifecycle hooks, extension-owned settings, and safe UI contributions.

Proposed solution

Introduce a versioned extension API with two sides:

1. Server/runtime extensions running in the T3 environment, with a scoped lifecycle and access to a stable subset of existing canonical runtime events.
2. Declarative client contributions sent through the existing typed RPC boundary and rendered by T3-owned components across supported clients.

A manifest could declare an extension ID, version, API version, required capabilities, settings fields, commands, lifecycle subscriptions, and UI contributions.

Initial lifecycle hooks could include:

• server ready/shutdown
• session started/exited
• turn started/completed/aborted
• request opened/resolved
• user input requested/resolved
• runtime errors

Initial settings fields could include text, password/secret, boolean, number, textarea, and select. Values should be namespaced by extension ID, validated on the server, preserve disabled/unknown extension configuration, and keep secrets out of client-visible settings.

Initial UI contributions should be deliberately constrained and host-rendered, for example:

• extension settings sections
• command-palette actions
• thread-header or composer actions
• status badges
• a constrained panel/card contribution

Extensions should invoke actions through fixed core RPC methods such as extensions.list, extensions.getSettings, extensions.updateSettings, and extensions.invokeAction, rather than dynamically adding RPC methods.

I do not think the first version should load arbitrary React components. Unlike Pi's single local TUI, T3 Code supports a potentially remote server plus web, desktop, and mobile clients that may be on different versions. A declarative contribution protocol would preserve the remote-ready and multi-surface architecture.

The existing scoped provider-driver registry appears to provide a useful lifecycle pattern for an ExtensionRegistry, while the canonical provider runtime events and schema-driven provider settings UI provide much of the underlying machinery already.

Why this matters

This would let users and organizations add internal integrations, notifications, accessibility helpers, workflow automations, and niche UI actions without requiring each one to become a core feature.

It would reduce pressure for large feature PRs and make it easier to keep private or experimental behavior isolated while still following upstream T3 Code releases.

Smallest useful scope

A narrow first implementation could include:

• Extensions loaded from explicitly configured environment-local paths.
• Explicit enable/disable and restart-based loading.
• A versioned manifest and compatibility check.
• Observe-only lifecycle hooks for server readiness, session lifecycle, settled turn completion, requests, user input, and errors.
• A generated extension settings page using a small serializable field schema.
• Command-palette actions plus one small UI slot, such as a thread-header action or status badge.
• Per-extension failure isolation, hook timeouts, and redacted secret storage.

Non-goals for the first version:

• marketplace or package discovery
• hot reload
• automatic execution of project-local extensions
• custom providers
• arbitrary React/client bundles
• blocking or event-mutating hooks
• full parity with Pi's extension API

Alternatives considered

1. Maintain a permanent fork. This works, but makes upstream updates progressively harder and duplicates work across users with similar integrations.
2. Add every integration directly to core. This expands product and maintenance scope.
3. Expose only webhooks or shell notification commands. Useful for Feature request: local lifecycle hooks / notification integration for tools like peon-ping #376-style notifications, but insufficient for settings and UI integration.
4. Load arbitrary client bundles. Flexible, but creates substantial security, compatibility, remote-client, and mobile problems.
5. Use provider-specific hooks. These do not provide a consistent T3-level lifecycle and cannot expose T3 UI contributions.

Risks or tradeoffs

• Extensions may execute near sensitive filesystem data and provider credentials.
• A public extension API creates long-term compatibility obligations while T3 Code is evolving quickly.
• Slow or broken hooks could affect runtime performance without strict timeouts and isolation.
• UI contributions need defined behavior across web, desktop, mobile, local, and remote connections.
• Server/client version skew requires API-version and capability negotiation.
• Multiple extensions may conflict or depend on ordering.
• Because T3 wraps external provider CLIs rather than owning every provider's agent loop, some Pi-style blocking or tool-mutation hooks may not be implementable consistently.

Project-local extensions should never execute without an explicit trust decision. Extensions should declare capabilities, be failure-isolated, use bounded event delivery, and receive redacted settings. A worker or child-process boundary would be preferable; any in-process first version should be described as trusted-only.

Examples or references

• Pi extension API: https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/docs/extensions.md
• Existing extension/marketplace RFC: [Feature]: [RFC] Extension System / Marketplace for custom integrations #1582
• Existing lifecycle notification request: Feature request: local lifecycle hooks / notification integration for tools like peon-ping #376
• Existing internal panel host proposal: [Feature]: Internal panel host for first-party panel composition #1377
• T3 architecture overview: https://github.com/pingdotgg/t3code/blob/main/docs/internals/overview.md
• Provider driver lifecycle pattern: https://github.com/pingdotgg/t3code/blob/main/apps/server/src/provider/ProviderDriver.ts
• Canonical runtime events: https://github.com/pingdotgg/t3code/blob/main/packages/contracts/src/providerRuntime.ts
• Settings contracts: https://github.com/pingdotgg/t3code/blob/main/packages/contracts/src/settings.ts

Contribution

• I would be open to helping implement this.

I would be happy to start with a small contracts/registry proof of concept after maintainers confirm the desired boundary and smallest acceptable scope.

[saphid]

A Pi status line and a plugin system, opened as a stack of ready PRs.

This is a concrete answer to this request (and #6714, #14557), finished so you can judge real code instead of a sketch. No maintainer has agreed to the direction yet. If the answer is no, we close the plugin PRs; the Pi status PRs stand on their own. Each PR was tested at its own head, reviewed, and has real-client evidence: web and desktop, Android where mobile changes, live agent turns where a provider is involved, and a remote --share pass where the change crosses the wire. GitHub can't stack PRs from a fork, so each targets main and includes the commits below it. Each body says which commit to review. They sit on the panel host stack listed on #14938.

Pi extension statuses

• feat(pi): show extension statuses in the thread header #16045: shows Pi extension statuses in the thread header (web/desktop).
• feat(mobile): show Pi extension statuses under the thread header #16046: the same statuses on mobile, under the thread header.

Plugin system (local plugins, explicit consent, each in a supervised child process)

• feat(server): run consented local plugins in supervised child processes #16047: plugin host and catalogue. This is a foundation: nothing runs a plugin until feat(server): deliver finished runs to plugins from an acknowledged cursor #16048, so review the two together.
• feat(server): deliver finished runs to plugins from an acknowledged cursor #16048: delivers finished runs to plugins from an acknowledged cursor.
• feat(server): let agents list and call plugin tools through MCP #16049: lets agents list and call plugin tools through T3's MCP server.
• feat(server): typed plugin settings, write-only secrets and plugin storage #16050: typed plugin settings, write-only secrets and plugin storage.
• feat: offer plugin actions in the palette, slash menu and thread menus #16051: plugin actions in the command palette, slash menu and thread menus.
• feat: show plugin views as isolated right-panel tabs on web and desktop #16053: plugin views as isolated right-panel tabs on web and desktop.
• feat(server): install plugins from npm with integrity checks and staged updates #16054: installs plugins from npm with integrity checks and staged updates.
• feat(web,mobile): manage plugins in Settings #16055: manages plugins in Settings. Mobile is read-only for now, because mobile pairings are standard-scope.
• feat(web,mobile): fill in plugin settings from Settings #16056: plugin settings forms.
• feat(web,mobile): install and update plugins from npm in Settings #16057: npm install and update in Settings.
• feat(web,mobile): show what each plugin adds and what its capabilities allow #16058: shows what each plugin adds and what its capabilities allow.
• feat(server,web,mobile): let plugins show statuses on threads #16061: lets plugins show statuses on threads (reuses the Pi status channel).
• feat(server,web,mobile): let plugins send notifications #16062: lets plugins send notifications.
• feat(server,web,mobile): let plugins add context to the turns you send #16063: lets plugins add context to the turns you send.
• fix(server): keep a user's approval answer when Pi, OpenCode or Muse confirm it #16064: lets plugins answer approval requests.
• docs(plugins): add example plugins and record plugin trust constraints #16065: example plugins, plus the trust constraints the system guarantees (docs/internals/plugins.md).

Out of scope: plugin administration from mobile, and a mobile view host for plugin views. Both are named in the PR bodies as follow-ups.

[Gabrielgvl]

Adding a concrete use case for the plugin stack above, from running the
T3 nightly as the substrate for a multi-agent setup (Claude, Codex, pi,
and Devin via ACP).

We supervise many threads with an external judge service and need:

1. Pre-dispatch model selection: before a run starts, ask an external
   service which provider instance/model to use (like
   t3.transform.enrich, but able to set modelSelection).
2. Finished-run delivery: feat(server): deliver finished runs to plugins from an acknowledged cursor #16048 covers this.
3. Plugin-initiated thread commands: send a follow-up message (re-prompt
   when a mechanical check fails) and provider.switch when a provider
   hits a usage limit. We do this today from a sidecar over the WebSocket
   protocol. It works on nightly, but it is unversioned
   (orchestrationProtocol=2 replaced thread.turn.start with
   message.dispatch).
4. Live run events for supervision (stall detection, nudges).

Is plugin-initiated dispatch in scope for the plugin host, or is a
versioned external client API the intended path? If maintainers approve
a direction, we'd be glad to test this stack against the use case and
contribute the missing capability as a focused PR.

[artile]

A use case from Paseo: client-side behavior that the proposed stack does not cover.

I use a private Paseo client plugin (11 features, about 2,000 lines). I moved to T3 Code and had to port each feature into a fork, because T3 Code has no plugin system. The stack in #16047–#16065 covers server-side work: finished runs, MCP tools, settings, palette actions and right-panel views. Most of my plugin is client-side behavior, and the stack has no place for it.

What the plugin does, and what extension point each feature needs:

Feature	Extension point that it needs
Select text in a message, type a comment, press Enter; the quote goes to the composer	Message selection actions (user and assistant messages) and a composer insert API
Double-click on MR-559 selects the full ticket id	Selection rules for chat text
Cmd+G opens https://<tracker>/task/<selection> in the in-app browser	Keybinding to a plugin action that gets the current selection; an API to open a URL in the preview panel
A strong thread match in Cmd+K comes before the actions	Palette ranking, or a plugin palette source with a score
Clicking a notification opens the chat at the start of the final answer, with a marker	Notification-click hook and a "scroll to message" API
Send while scrolled up does not move the chat	Chat scroll policy (could be a core setting instead)
Cmd+R renames the thread; Cmd+Shift+M + Cmd+1–9 pick a model	Keybinding to built-in commands (T3 Code has most of these already)
Ukrainian TTS through a local OpenAI-compatible speech endpoint	A speech-output provider slot

Paseo gives plugins a client context (addSurface, command center items, composer pills, timeline renderers, slash commands). With it, I could ship all of the above without a fork. When a Paseo update changed the DOM, my plugin broke. Thus, I agree that the host must own the rendering. But a declarative-only API cannot express behavior like "what happens when I select text".

Request: add a small, versioned client extension surface next to the server plugin host:

1. Bind keybindings to plugin actions, and give the action the current selection and the active thread.
2. Selection actions on user and assistant messages (the host renders the menu).
3. Client APIs to insert text or a quote into the composer, open a URL in the preview panel, and scroll to a message.
4. A notification-click hook.

Web and desktop are enough to start. Mobile can show "not supported".

Written with Claude Opus 5.5 in Claude Code.

[Zeus-Deus]

I've been trying out plugins for T3 Code myself. The goal was to make it as extensible as possible, so a plugin can add almost anything to T3 (views, sidebars, actions, settings, tools for agents) without breaking the official app. If a T3 update breaks a plugin, the worst case is that the plugin goes unavailable: T3 keeps working and your plugin data is kept. Plugins install on the server, so they work on web, desktop and mobile.

(Claude made the video but you get the idea)

plugins-intro.mp4

Realms is the one I use daily. Each agent gets its own screen, either a Linux desktop or a full Omarchy VM, so it can run and test apps without touching my desktop. I can watch it live next to the thread and take control whenever I want.

Project Coordinator was a test of how far it goes: Claude Code Projects–style, where each project is one conversation that hands work to threads nested under it.

Try it: plugin-system branch. The plugin guide is here.

[P4rcev4l]

Thanks for the proposal, and for the work in the PR stack.

A concrete use case: I run several agents (Codex and Claude Code) through T3 Code and want those agents to extend T3 for me. Examples are an action list of things waiting on me, a coordinator dashboard across threads, read-aloud of replies, and small status widgets.

I'd back the scope in the original post: a versioned, declarative extension API with host-rendered contributions (settings, command-palette actions, status badges, one constrained panel) and observe-only lifecycle hooks, loaded from explicitly configured local paths. That seems easier to review and keeps remote, mobile and version-skew behavior manageable. A stack of roughly 50k lines is hard to assess as a single unit, so a small first slice may be easier for maintainers to agree on.

A smaller ask that would already help: a documented theming contract, or stable data-* attributes on the main UI regions, so local styling does not depend on Tailwind class names.

[gsemet]

I would be glad to contribute to a best-in-class markdown edition surface with https://github.com/gsemet/markdown-okf-schema-studio

[xkjjx]

We should potentially consolidate discussion to #6714 ?

[Anneo22]

A use case from running the Pi agent inside T3 Code daily. We cover these today with Pi-side extensions, which work but add prompt tokens to every request and cannot touch T3's UI:

1. a status-line item showing each subscription's usage pace, in deficit or surplus against its reset;
2. a sidebar card per project showing its "waiting on you" queue, read from a markdown file;
3. hooks when a thread starts and when a turn settles, to load project context or save a snapshot.

A small surface (status items, a sidebar panel, thread and turn lifecycle hooks) would cover all three without a fork.

[Alb11747]

Adding my public fork, Alb11747/t3code, as a living source of concrete use cases for the extension API. I'd like to move its optional features into plugins where practical, so I can follow upstream without maintaining those patches.

The maintained references are:

• Fork changes: the current feature/patch inventory, why each exists, and related upstream issues/PRs.
• Fork usage guide: user-facing behavior and configuration.
• Fork guide: maintenance context.

Representative requirements include provider request/launch and compaction hooks (proxy keep-warm controls and cache behavior); run failure/retry and quota-reset handling; durable issue watches and delegation completion policies; scheduling options; composer predictions, thread status/actions and file-link downloads; and desktop close-to-tray behavior.

Please treat these as use cases to check the proposed extension boundaries against, including web/desktop/mobile and remote environments where applicable. Some are core bug fixes or release tooling and may appropriately remain core/fork changes. The goal is to make the optional behavior expressible through supported APIs, rather than assume every patch belongs in a plugin.

For future contributors and agents: read the latest main versions of the linked docs when assessing coverage. This summary is only a snapshot; the inventory will gain and retire features as the fork evolves.

[andras-gyarmati]

a use case from moving to T3 from the claude desktop app, where i had built a few claude code mods (usage bars, progress for background jobs, quick prompt buttons, a pane of open questions). none of them carry over to T3, and they only ever worked for one harness anyway

what i would hope this API gets right:

• agent agnostic: an extension shouldn't care which harness runs the thread, and it should be able to take data from outside the model (a file, a script, a local endpoint) so it costs no prompt tokens
• a small set of UI surfaces extensions can draw into: near the composer, a status strip, a side pane, notifications, and actions that send a prompt to a thread
• cross thread views, since a lot of the useful stuff is about many threads at once (what is waiting on me, what is still running)
• settings per extension in T3's settings

happy to test a nightly against this