feat(desktop): add Project connection setup

[wolfyy970]

Summary

Adds Connections to each Project so a stdio MCP service can be configured and tested once instead of being recreated for every agent.

Connections and credentials stay local to the Project, outside portable agent configuration. This slice covers secret handling, connection testing, tool discovery and removal. Agent bindings follow separately.

This keeps credentials out of portable templates and gives later agent bindings one Project-owned connection model. HTTP support remains with #4271 and the shared transport schema in #4164.

Related issue

#4301

This complements #4571, which configures remote MCP servers on individual Fly agents. This PR establishes the reusable Project-owned connection boundary.

Testing

• 28 focused Rust tests
• clippy
• desktop checks and typecheck
• E2E build and screenshot test

[wolfyy970]

Screenshots

Project connection ready

Add a Project connection

Remove connection confirmation

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 730c235447

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[wolfyy970]

@Annedaynl @custard-pirate, this is the Project-owned stdio connection half of the MCP work in #4571 and #4271. I would value your read on the boundary before I add agent bindings.

[matthewdonsemail-lab]

Great work on this — merge this so Desktop can have properly scoped MCP connections!

Our exact pain point (reproduced today):

We're running a managed Buzz agent (Social Media Outreacher) that needs persistent browser automation via @playwright/mcp. The workflow:

1. We added the playwright MCP server to .mcp.json in the agent's working directory with the correct --user-data-dir and --executable-path args.
2. Restarted Buzz Desktop multiple times.
3. The agent session reports zero playwright tools available — only the built-in buzz-dev-mcp tools appear.

The root cause we identified: there is no path in the current Desktop for an agent session to consume an .mcp.json-defined stdio server. The server runs fine when launched manually (node cli.js ... exits cleanly), so it is not a startup crash — the Desktop simply never wires the tools through to the agent.

This forces a painful workaround: chain all browser automation steps into a single shell call (open --headed & sleep 4 && goto && snapshot), because the browser is a child process of the shell and is killed when the shell exits. Multi-step interactive sessions are impossible this way.

Why this PR directly fixes it:

This PR establishes a Project-owned connection model for stdio MCP servers — configured and tested once, discoverable by agents bound to that project. That is exactly the missing layer. Once agent bindings land on top of this, the playwright server will be visible to the agent session without any shell workaround.

Suggested follow-up after merge:

• Surface a UI indicator in Desktop when a Project MCP connection is active and its tools are injected into an agent session (right now there is no feedback — you have no idea if the server loaded or silently failed).
• Document the end-to-end flow: add connection → bind agent → confirm tools visible in session. Issue Docs: how to connect an external MCP server (Olostep) to Buzz agents? #4515 tracks this doc gap.

Looking forward to the agent bindings PR.

[wolfyy970]

Thanks for documenting the repro. It confirms the split I’m implementing: this PR gives a Project tested, device-local MCP connections; the follow-up binds selected connections to an agent and carries them through the shared LaunchSpec. I’m restacking both on current main. I’ll link the replacement binding PR here and on #4852 once it is clean.

[ScaleLeanChris]

Tested current head 43fb7825 on Apple Silicon macOS with the focused Project connection gates.

• Project connection secret validation: 7/7 passed
• Desktop E2E build: passed
• Project connection interaction scenarios: 11/11 passed
• Focused Tauri backend checks: 27/27 passed
• Synthetic MCP initialize + tools/list discovery: passed

The interaction run covered setup, verification, removal, stale approval review, per-row progress, tool inspection, recoverable failures, maximum text zoom, validation boundaries, and a Project with zero repositories.

One local test-portability finding: with the normal Homebrew PATH, resolve_command("node") returns the symlink /opt/homebrew/bin/node. The synthetic probe test stores that noncanonical path directly, while verify_saved_executable canonicalizes it to the Cellar binary and then rejects the fixture as changed. Running the same test with the canonical Cellar Node path passes. The production create/update paths already call canonical_connection_command, so this appears limited to the test fixture. Using canonical_connection_command in synthetic_server_proves_initialize_and_tool_discovery, as the neighboring approval tests do, should make the focused test reproducible on Homebrew installations.

No source changes made.

[wolfyy970]

Thanks, this was a real portability bug in the fixture. Fixed in 6687805: the test now canonicalizes the resolved executable before storing the command and computing its approval hash. The focused synthetic MCP test passes cleanly on Apple Silicon.