Motivation
cargo-hauler ships an MCP App (ui://cargo-hauler/dashboard.html, a live view of queued/running cargo builds, lanes, admission, kache priors). Operators want hauler dashboard to open it in a browser against the running daemon — outside any MCP host, from a terminal. Today the only ways to see the App are (a) inside a host that supports MCP Apps, or (b) the dev Workbench's "App preview" tab, which requires agent-bundle dev and several clicks.
The framework already owns the whole host side — McpAppBridge, ui/initialize, tools/call proxying, consent authority, sandbox/document policy (packages/agent-bundle/src/dev/mcp-app-runtime-preview-service.ts, mcp-apps/mcp-app-sandbox.ts) — but exposes it only through the Workbench and the browser test harness (mountBrowserApp in agent-bundle/test). So a plugin that wants "open the dashboard" must hand-roll a bridge (cargo-hauler had a ~100-line scripts/preview-dashboard.mjs doing exactly that; it was removed because host machinery is not the plugin's to maintain).
Request
- CLI:
agent-bundle serve-app <server>/<app> [--target <host>] [--port N] [--open] [--tool <name> --input <json>] — bind a session to the built server (like the Workbench does), serve the App's HTML at http://127.0.0.1:<port>/ inside the framework's sandboxed host page with the real bridge, optionally call the App's backing tool first (hauler_status here) so it opens populated, and open the default browser with --open. Same consent/sandbox policy as the Workbench preview, same profile selection.
- Runtime helper so a plugin route can do it programmatically: e.g.
serveMcpApp({ server: 'hauler', app: 'dashboard', open: true }) from agent-bundle (or a script-friendly export), returning { url, close }. cargo-hauler would then add a hauler dashboard CLI route that calls it.
- Document it next to MCP Apps in
docs/framework-mode.md / the docsite, including that it is a local-only preview host, not a deployment target.
Non-goals
Not asking for a production web server or auth; loopback only, one session, process-lifetime.
Version
agent-bundle preview 42539ff5f (main).
Motivation
cargo-hauler ships an MCP App (
ui://cargo-hauler/dashboard.html, a live view of queued/running cargo builds, lanes, admission, kache priors). Operators wanthauler dashboardto open it in a browser against the running daemon — outside any MCP host, from a terminal. Today the only ways to see the App are (a) inside a host that supports MCP Apps, or (b) the dev Workbench's "App preview" tab, which requiresagent-bundle devand several clicks.The framework already owns the whole host side —
McpAppBridge,ui/initialize,tools/callproxying, consent authority, sandbox/document policy (packages/agent-bundle/src/dev/mcp-app-runtime-preview-service.ts,mcp-apps/mcp-app-sandbox.ts) — but exposes it only through the Workbench and the browser test harness (mountBrowserAppinagent-bundle/test). So a plugin that wants "open the dashboard" must hand-roll a bridge (cargo-hauler had a ~100-linescripts/preview-dashboard.mjsdoing exactly that; it was removed because host machinery is not the plugin's to maintain).Request
agent-bundle serve-app <server>/<app> [--target <host>] [--port N] [--open] [--tool <name> --input <json>]— bind a session to the built server (like the Workbench does), serve the App's HTML athttp://127.0.0.1:<port>/inside the framework's sandboxed host page with the real bridge, optionally call the App's backing tool first (hauler_statushere) so it opens populated, and open the default browser with--open. Same consent/sandbox policy as the Workbench preview, same profile selection.serveMcpApp({ server: 'hauler', app: 'dashboard', open: true })fromagent-bundle(or a script-friendly export), returning{ url, close }. cargo-hauler would then add ahauler dashboardCLI route that calls it.docs/framework-mode.md/ the docsite, including that it is a local-only preview host, not a deployment target.Non-goals
Not asking for a production web server or auth; loopback only, one session, process-lifetime.
Version
agent-bundle preview
42539ff5f(main).