[FEATURE] Convert the awkward Plugins, Marketpace and MCP editors in TUI to Web GUI (when available)

These are invoked using

/plugin-editor
/mcp-editor

mod installed commands. They use a simple web server and chrome with --app flag for a bare window. It would be a WebView..

IMO most of the awkward builtin slash command interaction should be converted tp something like this when a GUI context is available. Of course for non GUI context the fallback could be TUI.

Addendum: a concrete shape for this, and why it's low-risk

Why now. I built two editors as a proof of concept (a plugins/marketplaces editor replacing /plugin, and an MCP editor replacing /mcp). Each has a master/detail tree, filters, a form with a raw JSON tab, masked secrets, and light/dark/system themes. See the screenshots above. Each editor took a few hours. The hard part was the plumbing the mod API doesn't provide. A mod can't open a page, so the mod spawns a local Node server with $.process.spawn, and the server launches a Chrome --app window and calls the claude CLI. That works only in the CLI ($.process is CLI-only), so none of it can run in Claude Code Desktop or the IDE extensions.

Where it fits. The mod types (Claude Code 2.1.296) already contain most of the pieces:

• Svg is drawn in a sandboxed frame on the remote surfaces when marked interactive.
• Client posts plain JSON from its drawing code to the mod's hooks module as ui.message, and the hook can answer with { props }.
• A Client's module is a literal path to a file in the mod's own folder.

Proposal. An optional WebView element:
<WebView key src="./ui/index.html" props={...} width height />

• It is available on surfaces that are already web-based (desktop, VS Code). The terminal could open a window or fall back to a line of text, as Image already does.
• The page runs in a sandboxed iframe with a strict CSP.
• It talks to the mod's hooks module over the existing ui.message channel (postMessage out, props in).
• The mod declares it in the manifest and the user approves it once, like $.process and $.fs.

On risk. Mods can already run processes, so a sandboxed page is less powerful than what the CLI already allows. The sandbox only has to keep the mod's HTML away from the host page, its storage, and other plugins. The one new exposure is on desktop, where mods currently can't run commands, so I'd gate the webview with the same approval as $.process.

Why it matters. Several built-in screens (/plugin, /mcp, settings, permissions, sessions) are tables and forms that are awkward in a cell grid. With a first-class webview, users and plugin authors could ship real editors that work in every host, with no side server or separate window.

Here is the repo for the implementation : https://github.com/sandipchitale/gui-editor