Auto-connect stdio MCP servers; store env as connection secrets (#1129)

* Auto-connect stdio MCP servers; store env as connection secrets Adding a stdio MCP server registered an integration but no connection, so the v1.5 per-connection tool model produced zero tools on a fresh install. Auto-create the default connection on add (no-auth, or one-shot env values), declare secret env vars as a stdio_env auth method whose values live on the connection's secret store, add a boot-time reconcile for pre-existing stdio integrations, and give the add form a TagInput for declaring env var names. * Derive stdio MCP display name from the package, not the runner The stdio add form fell back to the bare command (npx, uvx, ...) for both the display name and namespace, so every npm-launched server landed as "npx". Derive a name from the package/module being run instead: skip the runner and its flags/subcommands, drop the npm scope, version, path, and the usual MCP affixes (mcp-server-, server-, -mcp), then title-case. So "npx -y @modelcontextprotocol/server-github" becomes "Github MCP" and "uvx mcp-server-time" becomes "Time MCP", falling back to the raw command when nothing meaningful can be extracted. * Run the local e2e project in CI The local vitest project (e2e/local/**, including the stdio MCP auto-connect coverage) was excluded from both the default e2e chain and root `bun run test`, so it never ran in CI. Add a test:local script and a dedicated CI job that boots the scenarios with Node 22 and Chromium installed, since each one launches a real executor web server and some drive a browser. * Fix ci.yml: restore desktop-smoke job header The previous commit's edit consumed the desktop-smoke job header when inserting e2e-local, leaving its body orphaned with a duplicate steps key. GitHub rejected the workflow on startup. Restore the header. * Make local e2e reliable in CI: serialize boots, add headless shell The local project booted its executor web servers with file parallelism on, the only server-booting project that did. On a CI runner several cold vite boots at once thrashed past the token-URL wait, timing out stdio-mcp and auth. Run the files serially like every other server-booting project so the first boot warms the vite cache. Also install chromium-headless-shell, which the browser scenarios launch and which does not come with the chromium download. * Install Playwright browsers via e2e's pinned version Running the install from the repo root let bunx float to the latest playwright, which fetched a browser build the test runtime (playwright 1.60.0, pinned in e2e) never looks for, so the browser scenarios failed to launch. Install from e2e so the resolved playwright matches the one the scenarios use. * Scope the e2e CI job to the stdio MCP scenario Running the whole local project in one CI job stacked several executor web + vite boots on the runner; a later boot would intermittently stall past the token-URL wait, and the auth scenario carries its own pre-existing browser flakiness. Run just the stdio MCP scenario, the auto-connect / env-as-secret regression guard, on its own so the job is a reliable gate. Also give the cold-boot wait headroom (120s to 180s) for CI runners. Expanding to the full local suite is a follow-up once the rest is stabilized.

RSRhys Sullivan committed 4 months ago