Dashboard: let embedding tools limit engines, providers and the Chat tab

[Amronos]

Problem

Tools that embed the dashboard in their own UI can't trim it to what they support. For example, a workspace app that proxies the dashboard into a panel and only manages local Chrome still shows Lightpanda, AgentCore, Browserbase, Browserless, Browser Use and Kernel in the New Session dialog, plus a Chat tab that opens by default. Choosing one of those options fails or does something the host app doesn't manage. Today the only way to remove them is to string-replace the minified JS that the dashboard serves, which breaks on every release.

What the dashboard does today:

• BROWSER_OPTIONS in session-tree.tsx hardcodes Chrome, Lightpanda and the five cloud providers. The list doesn't come from the server, so it also can't show providers added by plugins.
• page.tsx always renders the Chat tab with defaultValue="chat".
• /api/chat/status already returns {"enabled": false} when AI_GATEWAY_API_KEY is unset, and useChatStatusSync stores it in chatEnabledAtom, but nothing reads that atom. Without a key, users land on a Chat tab whose first message fails with "AI_GATEWAY_API_KEY not set".

Proposal

1. Use the chat status the dashboard already fetches

When /api/chat/status reports enabled: false, hide the Chat tab and open Activity by default. This needs no new option. An embedder that doesn't want chat starts the dashboard without AI_GATEWAY_API_KEY.

If hiding the tab makes chat too hard to discover, the alternative is to keep the tab, open Activity by default, and show a setup hint in the Chat panel. That would still need an option for embedders.

2. Let dashboard start limit engines and providers

These options follow the --allowed-origins / AGENT_BROWSER_DASHBOARD_ALLOWED_ORIGINS pattern:

Flag	Environment variable	Default
--engines <list>	AGENT_BROWSER_DASHBOARD_ENGINES	Every engine the dashboard supports
--providers <list|none>	AGENT_BROWSER_DASHBOARD_PROVIDERS	Every built-in provider

agent-browser dashboard start --engines chrome --providers none

• Unknown names fail startup, the same way malformed origins do.
• The values join the port and allowed origins in the settings that a repeated dashboard start must match.
• The MCP agent_browser_dashboard_start tool gets matching engines and providers arguments.

The UI would read one endpoint instead of /api/chat/status, for example GET /api/dashboard/config:

{
  "engines": ["chrome"],
  "providers": [],
  "chat": { "enabled": false }
}

The New Session dialog would build its browser buttons from these lists and hide the picker when only one option is left. The server and UI ship in the same binary, so /api/chat/status could be replaced instead of kept.

This only changes what the UI offers. It isn't a security boundary, because /api/exec still runs any CLI command.

Alternative: derive the providers from credentials

doctor already maps each provider to its API key variable. The dashboard could list only providers whose credentials are set, and only engines that are installed. That avoids new flags but has two downsides: new users stop seeing which providers exist, and an embedder still can't hide an engine that happens to be installed, such as Lightpanda.

Questions

1. For chat, do you prefer hiding the tab when it's disabled, or keeping it with a setup hint?
2. For engines and providers, do you prefer explicit dashboard start options, derived availability, or both (derived by default, options to narrow it)?
3. Is /api/dashboard/config a good name for the endpoint, or would you rather extend an existing one?

I can open a PR for whichever design you prefer. A related PR, #2524, lets the dashboard run under a reverse-proxy path prefix, which is how these tools usually mount it.

Written by Opus 5.5 (opus-5.5) through Sprocket.