[RFC]: Plugins without a plugin runtime — MCP, skills, and hooks in 4 PRs

[rakibulrocky14]

Problem or use case

Adding an integration to T3 Code today means landing a core PR or maintaining a fork. People keep asking for an alternative: a Pi-style extension API (#6837), an extension/marketplace system (#6714), one plugin and skills list across providers (#6987), and managing Codex plugins inside T3 Code (#14310). Meanwhile, anyone who switches providers has to set up the same MCP servers and skills again in each one.

Proposed solution

A small, versioned plugin system, delivered as an MVP in 4 PRs. Each PR is useful on its own, aims for under ~2,000 changed lines including tests, and leaves T3 fully working if later PRs never land.

1. Server core: a plugin is a folder with a versioned manifest that contributes MCP servers and data-declared settings. T3 merges plugin MCP configs at the shared session manager that feeds both the Codex and Claude adapters, and the provider launches them the same way it launches user-configured MCP servers today. Off by default.
2. Management UI (web + desktop): a Settings page and command palette entries to install, enable, disable, and remove plugins.
3. Skills: only if Codex and Claude can load them through one mechanism. I'll verify that before building.
4. Lifecycle hooks: plugins react to thread/turn events and can act on threads through ordinary commands. Only if the hook design below is approved.

Design details

Core rules

• Plugin code never runs inside the T3 server process, and the orchestrator's decider gains no plugin logic. PRs 1–3 need no orchestrator changes at all.
• PR 1 makes one small change at the shared session manager seam that feeds both adapters, so there are no per-provider branches.
• Plugins are environment-owned: installing means registering a path on the environment's machine. Remote and tunnel clients inherit them; nothing is read from a connecting client's filesystem.
• State lives in its own plugins.json beside the server settings. No file means plugins are off, so default behavior is unchanged and older builds never read it.
• Changes apply to new sessions; running sessions keep their config until restarted.
• The manifest is frozen for the MVP and additive-only afterward. Unknown fields are ignored, so an older T3 disables a too-new plugin instead of failing.
• MCP server names are namespaced as <plugin-id>-<server> using [a-z0-9-]. Collisions with a user's own server, another plugin, or T3's t3-code entry are rejected, never overwritten.
• Remove unregisters a plugin and clears its settings and secrets, but never deletes its folder.
• Providers that don't honor passed-through MCP config are shown as unsupported.

Secrets

• Secret settings are write-only toward clients: never returned over RPC, following the existing redacted-settings pattern.
• At rest, they're stored in plugins.json, the same model as inline provider secrets today, so they share the same exposure: plaintext on disk, protected by file permissions.
• plugins.json is created with owner-only permissions (0600 on macOS/Linux; on Windows it inherits the per-user access of T3's state directory) and is rewritten atomically with those same permissions.
• If T3 finds the file readable by other users, it logs a warning and restores owner-only permissions on the next write.

Hooks (PR 4)

• Hooks subscribe to lifecycle events such as "turn completed" or "turn failed."
• When a subscribed event is committed, the hook runs as an outbox effect in the existing effect worker: a one-shot command with the event as JSON on stdin, a timeout, and an output cap. No long-running processes or restarts.
• The hook returns actions from a fixed allowlist, each turned into an ordinary server command: add a note to the thread, or send a follow-up message that starts a new turn (for example, "tests failed, here's the output, fix it").
• The decider handles these like any other command, with plugin attribution. The only orchestration changes are new command/event types and their dispatch mapping.
• Hook-started turns are capped per thread (default 3 in a row), a failing or hanging hook never blocks a turn, and hook messages are visibly marked as coming from the plugin.

Why this matters

One plugin, installed once, works across providers and clients with no per-provider setup. Integrations stop needing core PRs or forks, and the core team doesn't have to own every integration.

Smallest useful scope

PR 1 alone: MCP servers plus data-declared settings for Codex and Claude, enabled by editing plugins.json. If the full MVP is too much right now, I'm happy to stop after PR 2 or PR 3.

Alternatives considered

Several plugin attempts came before this one, and this proposal is built on what they showed:

• Plugin system: host, SDK, capabilities, web host, and marketplace #3993 by @ccdwyer: a full in-process plugin host with a marketplace. It was closed because orchestration V2 (feat(orchestrator): introduce new orchestrator #2829) replaced the layer it was built on, explicitly not as a judgment on the work. I'd like to borrow its rule that policy hooks can only make the system stricter, never approve anything (question 3 below).
• feat(plugins): add local plugin system with shareable git sources #6158 by @yemirhan and feat: add unified plugin marketplace #7134: a Raycast-style local plugin system and a unified cross-provider marketplace. Both were closed as competing with the maintainer-owned plugin work below. feat: add unified plugin marketplace #7134 also shows real demand for managing plugins across providers.
• feat: add production plugin runtime #7480 → feat: add plugin command catalog #7549 → feat: add plugin package lifecycle #7613 → feat: add trusted local plugin system #8007 → feat: add trusted local plugin system #8014, requested by @UtkarshUsername: this series showed that a trusted local plugin system with a Settings page works end to end. feat: add trusted local plugin system #8014 was closed because the team didn't want to set up that large a trusted-plugin contract through one branch. This proposal keeps its trusted-local, environment-owned model, drops the in-process runtime, and splits delivery into small, independent PRs.
• [RFC]: Local app integration SDK and custom project surfaces MVP #6977 by @abcdmku: proposes plugins as web pages with an SDK and optional MCP tools for agents. I'm reusing its idea of exposing plugin tools to agents over MCP, with [a-z0-9-] names because they become tool prefixes. Its plugin-page approach could build on this later.

Risks or tradeoffs

• Not a sandbox: plugin MCP servers and hook commands run with the user's own permissions on their own machine. The docs and Settings page will say this plainly, including that an agent with filesystem access can already edit local config.
• Secrets at rest: plugin secrets are plaintext on disk behind owner-only file permissions, the same exposure inline provider secrets have today. If you'd prefer OS keychain storage, I can add that as a follow-up rather than in the MVP.
• Management is human-only: no MCP tool, hook, or agent-reachable RPC can install, enable, disable, or remove plugins.
• Hook-started turns cost tokens: the per-thread cap and plugin attribution keep this bounded and visible.
• Scope creep: the frozen manifest and per-PR size target are the guardrails. Out of scope for the MVP: marketplace, signing, custom plugin UI, and hooks that block or rewrite a turn before it runs.

Examples or references

• Previous PRs: Plugin system: host, SDK, capabilities, web host, and marketplace #3993, feat(plugins): add local plugin system with shareable git sources #6158, feat: add unified plugin marketplace #7134, feat: add production plugin runtime #7480, feat: add plugin command catalog #7549, feat: add plugin package lifecycle #7613, feat: add trusted local plugin system #8007, feat: add trusted local plugin system #8014
• Related RFCs and requests: [RFC]: Local app integration SDK and custom project surfaces MVP #6977, [Feature]: Pi-style extension API for lifecycle hooks, UI contributions, and settings #6837, [Feature]: [RFC] Extension System / Marketplace for custom integrations #6714, [Feature]: Abstract skills and plug ins across all providers #6987, Manage Codex plugins and service connections directly in T3 Code #14310
• Orchestration V2: feat(orchestrator): introduce new orchestrator #2829

Contribution

I'd like to build all four PRs myself, in order, and I won't open PR 1 until there's a maintainer reply here. Before I start, these are the decisions I need:

1. Is provider-launched MCP pass-through, with no process supervision in T3, the right transport?
2. Is this 4-PR MVP acceptable? If it's too much for now, I'll stop after PR 2 or PR 3.
3. For PR 4: are async hooks (outbox effects whose results come back as ordinary commands) the right design? Should hooks also be able to deny, never approve, approval requests, as Plugin system: host, SDK, capabilities, web host, and marketplace #3993 proposed?

Happy to adjust anything before writing code.

cc @juliusmarminge @t3dotgg