Let any Bot enable a remembered secret MCP server in its settings

[DoodleBears]

Requested by Vain

Why the change

A remembered MCP server and its secret belonged to the one Bot that set it up. Another Bot needing the same integration had to be set up separately and the Human had to enter the secret again. The owner asked for a server set up once to be something any Bot can turn on in its settings.

Closes #1613

Special things to note

• Merge risk: security boundary and a schema migration (generation 90, new table bot_secret_mcp_enabled). This is the first case where a private grant is used on behalf of a Bot other than the one it was given to. Revert by reverting this PR; the table stays and is ignored. Decision in ADR-0198. Review focus: the sharedFrom path in PrivateInputs.consume (credentials/private-inputs.ts), the reconnect, enable and admin code in credentials/mount.ts, credentials/secret-mcp-store.ts.
• Behaviour: a remembered server is listed under Secrets in every Bot's settings. For the Bot that set it up nothing changes. Every other Bot shows it with a switch that is off; turning it on connects the server for that Bot at once if its chat Session is running and at each later start, and turning it off stops that Bot's copy.
• The secret: each Bot runs its own server process, started by the Host with the secret of the Bot that set the server up. The enabling Bot gets the server's tools. It does not get the references and cannot use that secret through secret_http, secret_cli or a start of its own. Only the authenticated Owner can turn the switch; a Bot cannot.
• Stopping: every process is a registered use of the one grant, so revoking the account stops the server for all Bots. Deleting the Bot that set it up erases the record and the switches. Removing it in any Bot's settings removes it for all.
• Default off: an earlier state of this branch connected every Bot automatically. The owner then asked for a setting per Bot, so other Bots start with the switch off. That also limits which Bots other people can steer into calling the server from a Group or external IM.
• Not included: Assignments still do not get the server.
• Verification:
  • Automated: secret-mcp-store.test.ts covers enabling, disabling, listing per Bot and clean-up on removal; private-accounts-section.test.ts covers the owner row without a switch and another Bot turning the switch on. packages/core, packages/client, apps/docs, scripts/test: 3964 tests pass after a clean build. pnpm lint, pnpm format:check, pnpm typecheck pass. The shared consume path and the live connect have no unit test; the runtime runs below cover them.
  • Runtime, real model turns, isolated Profile on DSH 0.2.0-rc.2, the fixture server, two existing Bots:
    • Bot A connected the server with allow and remember. Bot B's settings listed it as set up by Bot A, not enabled, not connected.
    • After enabling it for Bot B, the list showed it connected, and Bot B, asked to call the tool without connecting anything, returned {"status":200}.
    • After disabling it for Bot B the list showed it not connected.
    • With it enabled, the Host was restarted and only Bot B was messaged, so Bot A's Session was not running: Bot B again returned {"status":200} with no start card.
    • The switch was also turned on from the settings page in the browser.
    • Removing the server through Bot B's settings stopped every server process and deleted the record and the switches.
  • Not verified: revoking the account while several Bots use the server; deleting the owning Bot; two Bots remembering servers with the same name; Groups; Windows and Linux.
  • Human QA: not done.

Change outline

remember (Bot A) -> record owned by Bot A -> Bot A reconnects at each start
Bot B settings > Secrets -> the server, "set up by Bot A", switch off
  switch on  -> Host starts Bot B's copy with Bot A's grant; Bot B gets tools only
  switch off -> Bot B's copy stops
revoke / delete Bot A / remove in any Bot's settings -> stops for all

Another Bot's settings before and after turning the switch on.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}