[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.