Before submitting
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
Before submitting
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
shellorfilesystempermissions, 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
Examples or references
Contribution