Add BlueNexus integration: 200+ connections via single OAuth grant

[tahpot]

What this adds

This PR adds BlueNexus to the connector registry so a QM user can link it from the Keychain page, and adds a seeded skill so the agent knows how to use it. The full, authoritative list of supported connectors lives at https://bluenexus.ai/connectors.

Users can connect all their accounts — Slack, Notion, GitHub, Google Workspace, Telegram and 200+ others, with several thousand tools between them — behind a single OAuth grant. A QM user who links it gets whichever of those services they've already connected.

Users can add custom MCP servers to their BlueNexus account, providing a quick way to support any MCP server until QM natively supports it (see #75).

Connections can be permissioned as read-only or read + write, which controls what the agent is able to do once connected. This connector defaults to read + write (universal-mcp-read-write), exposing all six BlueNexus tools. To run it read-only instead, change scopes to ["universal-mcp-read"] and register the BlueNexus app with that same scope — the two have to match, because BlueNexus rejects an authorization request asking for a scope the app does not allow.

I note the preference in CONTRIBUTING.MD for human feature PR's, but since we know our own API it seemed to make sense to do a traditional PR :)

Demo

▶️ Demo video:

https://www.loom.com/share/356ffacf7577440884d3cbf53298dafe

A short walkthrough: Keychain → Connect BlueNexus → consent → the agent listing and calling downstream tools from a single grant.

How it works

The model gets a small fixed tool surface and everything else runs through execute in the scope's sandbox. This connector does not change that. It follows the same shape as the existing Google, Dropbox and Linear connectors: core holds the credential, and a skill teaches the call.

1. Core stores the OAuth token in the keychain, encrypted with AES-256-GCM.
2. Each DM turn, core injects it into the sandbox as $VAULT_TOKEN_BLUENEXUS_AI, the same way $VAULT_TOKEN_WWW_GOOGLEAPIS_COM already works.
3. skills-seed/bluenexus-connections/SKILL.md tells the agent the endpoint, the JSON-RPC shape, the six tools, and the failure modes.
4. The agent calls https://api.bluenexus.ai/mcp with curl.

Note: No tools are added to the model's context. Several hundred downstream tools stay on the far side of one execute call, maximizing context window size for actual meaningful work.

Test changes

Two existing tests needed updating, both because the specification genuinely changed rather than to make them pass.

only X opts into PKCE (regression guard) asserted exactly one PKCE provider. BlueNexus is the second deliberate opt-in, so the guard now takes an explicit allowlist of x and bluenexus. The else branch is untouched, so a third accidental opt-in still fails.

the catalog endpoint exposes per-provider setup guidance pins the sorted provider list, which gained bluenexus.

One test was added: BlueNexus authorizes on the app host but exchanges on the api host, with PKCE and the read-write MCP scope. That pins the split-host quirk — authorize on app.bluenexus.ai, token exchange on api.bluenexus.ai — which is unique among the eight providers and the easiest thing to "tidy" into a single host and silently break.

Verification

tsc (root, cli, contract), prettier, eslint, oxlint and knip are clean.

CLI 503/503, web-ui 440/440, deployment stack contracts 1/1. Core is 3579/3713 with two failures in opencode-harness.test.ts and sandbox-noninteractive.test.ts; both were confirmed pre-existing by running them on unmodified 7f2c916, and neither file touches anything here.

Exercised end to end against production BlueNexus from a cold start: Keychain → Connect account → consent → callback → grant stored with a refresh token → the agent listing all six tools using the injected env var.

Setup

Create an OAuth client at BlueNexus → Developers → My Apps → Add App, in Third-Party Integration mode, grant it the same scope this connector requests (universal-mcp-read-write by default), and add <PUBLIC_URL>/v1/connectors/oauth/bluenexus/callback as its redirect URI. Clients can also be registered over the API; the registration_endpoint in https://api.bluenexus.ai/.well-known/oauth-authorization-server accepts RFC 7591 requests.

Then set the two secrets and restart:

BLUENEXUS_OAUTH_CLIENT_ID=client_...
BLUENEXUS_OAUTH_CLIENT_SECRET=...

qm check now fails when the client ID is set without the secret.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[odfalik]

read https://github.com/yc-software/qm/blob/main/CONTRIBUTING.md

[tahpot]

read https://github.com/yc-software/qm/blob/main/CONTRIBUTING.md

Thanks @odfalik

I mention that in the PR description.

I note the preference in CONTRIBUTING.MD for human feature PR's, but since we know our own API it seemed to make sense to do a traditional PR :)

If you still prefer a human written, happy to switch it up.