[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.
• feat(server,web,mobile): let plugins answer approval requests #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.