Skip to content

Extension framework: a VS Code-style plugin system for Prism Terminal with first-class Claude Code mod integration #118

Open
Open
Extension framework: a VS Code-style plugin system for Prism Terminal with first-class Claude Code mod integration#118

Description

@Maxaubert
Maxaubert
opened on Oct 4, 2026

Before anything else: when this issue is picked up, the work MUST start with the /grill-me skill with Max, to settle the design decisions before any spec, plan or code. Max wants this done correctly, not thrown together.

Owner, 2026-10-04 (relayed from a research session). This is the idea, not a decided design. The research behind it is C:\Users\Admin\Documents\Claude\research\prism-terminal\2026-10-04-mods-support-and-beyond.md, in particular B4 (bridge mod plus MCP server), B5 (rich panes) and B6 (the ui_* attach spike).

1. Vision

  • A real extension framework for Prism Terminal, comparable to VS Code's: extensions contribute UI and behaviour to the terminal.
  • Built-in, easy integration with Claude Code mods, hooks and Codex, so agent tooling can shape the terminal experience.
  • Not just a mod system, and not limited to buttons.

2. Possible contribution points

  • Overlays: buttons and chips over the terminal, for example a "Compact (70%)" button a mod shows when context is high.
  • Status and tabs: badges and decorations on tabs, and status items.
  • Panels: slide-over panels with rich content (Markdown, charts, lists, forms).
  • Commands: the command palette and context menus.
  • Notifications: notifications and toasts.
  • Settings and keys: settings pages and keybindings.
  • Rendering hooks: for links and paths.

3. Who can contribute

  • Native Prism extensions: a manifest plus code.
  • Claude Code mods: through a small "Prism SDK" snippet. Its calls do nothing outside Prism, so mods stay portable.
  • Hooks and Codex: Claude Code's classic hooks, and Codex.
  • Shell scripts: through a prism CLI or an OSC escape protocol.
  • Anyone: the protocol should be open, so any agent or tool can build UI.

4. Architecture sketch (to be decided in the grill-me session)

  • Manifest: each extension declares itself in one.
  • Declarative UI: extensions describe elements, which Prism renders natively in React with its theme tokens. No arbitrary HTML or JS in the main window. Rich panels only in a sandboxed iframe (srcdoc, no allow-same-origin, strict CSP).
  • Channel: a local, versioned channel between Prism main and extensions/mods, either a localhost hook server or a named pipe.
  • Events both ways: clicks, input and lifecycle from Prism; state updates from extensions.

5. Safety

  • Permissions: per extension, with trust levels.
  • Ownership: show which extension owns each element, with an on/off switch per extension.
  • The shell rule: an element never types into the shell on its own (the existing rule).
  • Mods may be absent: mods are unsandboxed and can be remotely disabled or blocked on managed machines, so the framework must not depend on mods existing.

6. Constraints from CLAUDE.md

  • Shared core: core/ is shared with the Prism media viewer (TermHostConfig, owner decisions).
  • For other people: a product that works on a fresh Windows install.
  • Scope: split panes and "shows files" are on the Out list, so overlays and slide-overs fit better.

7. Unknowns needing a short spike first

  • Can a mod keep a channel open to receive clicks from Prism, given mod hook budgets and no timers?
  • Can a mod trigger actions such as /compact itself, or only fill the prompt?
  • How stable is the mod API across 2.1.x?

8. What it would host later

This framework would also be the home for later features: status signals, Prism Guard, and the roster and inbox.

Research only so far: nothing has been changed in the repo.

Activity

  1. Maxaubert commented on Oct 10, 2026

    @Maxaubert
    Maxaubert
    on Oct 10, 2026
    OwnerAuthor

    Addition, owner 2026-10-10: built-in mods

    As well as mods users write themselves, Prism Terminal should come with pre-installed mods: some on by default, others the user can choose to turn on. A mod can reach the UI too, for example by adding buttons.

    The owner pointed to the agent indicator as the model: since #131 it runs on Claude Code hooks through a plugin the app ships with (core/claude-plugin, handed to each shell through CLAUDE_CODE_PLUGIN_DIRS, and switched on in Settings). Built-in mods could be bundled and delivered the same way.

    This is a general direction only. No specific mods have been chosen yet.

    Their words: "we want to build some pre-installed mods or mods the user can choose to enable and whether or not that could be like added with the tool like you already said that we could add the agent indicators based on hooks so this seems like a similar idea just with mods though it's just a general idea no specific mods"

  2. Maxaubert commented on Oct 12, 2026

    @Maxaubert
    Maxaubert
    on Oct 12, 2026
    OwnerAuthor

    Addition, owner 2026-10-12: architecture across the two apps

    The terminal in this repo also runs inside Prism (core/, see docs/two-apps.md). Mods have to fit that, so the design needs this settled in the grill-me session before anything else.

    The owner's words: "letting mods do things to the tab bar should be limited to just the terminal app, while general mod support for the terminal in general and maybe adding buttons on top of the terminal might be ok to do in prism too. im not sure, i want both to be as open as possible but i also dont want my terminal in prism to break or suck just cuz i created a mod for this terminal"

    The goal: both apps as open to mods as possible, without a mod written for Prism Terminal ever breaking or degrading the terminal in Prism.

    Proposed split (a starting point for the grill-me session, not decided)

    Split the contribution points by who owns the surface, the same line core/ and src/ already draw.

    1. Terminal points, in core/, available in both apps:

    • Buttons and chips over the terminal (the "Compact (70%)" example).
    • Notifications and toasts tied to a shell.
    • Rendering hooks for links and paths.
    • Commands that act on one terminal.

    2. App-shell points, in src/, Prism Terminal only:

    • The tab bar and the sidebar: badges, decorations, extra rows.
    • The title bar, the window's own buttons.
    • Settings pages, the app's keybindings, the menu.
    • Slide-over panels, unless we later decide Prism wants them too.

    Prism never sees group 2 at all. A mod that targets the tab bar simply has nothing to attach to in Prism, by design, not by accident.

    How a mod stays unable to break the terminal

    1. Declarative only. A mod describes elements; the host renders them with its own components and theme tokens. No mod code runs in the renderer, so a bad mod cannot throw inside the terminal, block typing or restyle it.
    2. A fixed place for each kind of element. Overlays go into reserved slots (for example a corner row over the terminal) that cannot cover the prompt, the scrollback or the cursor, and have a cap on how many show at once.
    3. Fails closed. A mod that sends invalid data, times out or floods the channel is dropped and its elements removed. The terminal carries on as if it had no mods. Each element sits behind an error boundary.
    4. The host decides, per app. Mod support in core/ would be a declared TermHostConfig field (which is an owner decision per core/README.md), for example mods: 'off' | 'terminal'. Prism can start with it off or limited and open it up later, without forking the core.
    5. Per-app on/off per mod. A mod switched on in Prism Terminal is not automatically on in Prism. Each app has its own list and its own built-in mods (see the 2026-10-10 addition).
    6. The existing rules hold. A mod element never types into the shell on its own (regression rule 2), and the indicator stays the agent's own word (rules 8 and 9): a mod can add to the UI, not override them.
    7. Tests in both hosts. Every terminal-level contribution point gets an e2e in Prism Terminal and a check in Prism's terminal gate, so a mod API change that would hurt Prism fails before it ships.

    Questions for the grill-me session

    • Should Prism get terminal-level mods from day one, or start with them off and opt in later?
    • Do slide-over panels belong to the terminal (both apps) or the app shell (Prism Terminal only)?
    • Does a mod declare which app(s) it targets, or does it just declare contribution points and each app shows what it supports?
    • Built-in mods: one shared set, or a separate set per app?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions