Skip to content

[Feature]: Extension Marketplace UI #3

Description

@vernonthedev

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

apps/desktop

Problem or use case

Once the extensions system exists, there is no user-facing surface to discover, install, manage, or audit extensions. Users would need to manually drop files into ~/.t3code/extensions/ and have no visibility into what is installed, what permissions each extension holds, or whether extensions are active. This creates a poor and opaque developer experience.

Proposed solution

An in-app Extension Marketplace panel with two sections: a registry browser for discovering and installing extensions, and an installed extensions manager for runtime control.

Registry browser:

  • Search/filter extensions by name, category, or permission scope

  • Extension cards showing name, description, author, version, and declared permissions

  • One-click install (local drop-in for MVP; registry fetch in future)

  • Link to source / documentation per extension
    Installed extensions manager:

  • List of all installed extensions with current status (enabled / disabled / error)

  • Per-extension toggle (enable/disable without uninstalling)

  • Declared permissions displayed clearly per extension (e.g., git, shell, filesystem)

  • Uninstall action

  • Last-used timestamp and tool invocation count (pulled from execution logs)
    Permission visibility:

Before enabling any extension that declares shell or filesystem permissions, show an explicit confirmation prompt listing the permissions being granted. This mirrors the model used by browser extension stores.

Why this matters

Discovery and trust are the two blockers for extension ecosystem adoption. Without a UI, only technically confident users will install extensions at all. A marketplace surface lowers the barrier to entry and surfaces permission information at the right moment, before the user enables the extension, not after something goes wrong.

Smallest useful scope

An installed extensions panel only (no registry browser): list installed extensions, show their declared permissions, and provide enable/disable/uninstall controls. Registry browsing can follow once the backend extension index exists.

Alternatives considered

Settings page with a plain list of extension folder names, rejected because it gives no permission visibility, no status feedback, and no path to discovery. It also requires users to know the folder path to manage anything.

Risks or tradeoffs

  • The registry backend (an index of published extensions) is a separate infrastructure concern and should not block the installed manager UI.
  • Displaying permissions requires the manifest parser to be reliable, if manifests are malformed, the UI needs a clear fallback state.
  • Install-from-URL in the UI introduces a supply-chain risk vector; that path should be gated behind an explicit "advanced" disclosure.

Examples or references

Contribution

  • I would be open to helping implement this.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    Status
    Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions