[Feat] Deployment-scoped custom MCP servers (remote, OAuth, and stdio)

[mrubens]

[Feat] Deployment-scoped custom MCP servers (remote + OAuth + stdio)

Closes #1142.

Adds a Custom MCP Servers section to Settings → Integrations where deployment admins can connect MCP servers that are not in the built-in catalog. Custom servers become available to agents in every task.

What's supported

• Remote servers (streamable HTTP) with no auth, static header auth, or OAuth. Remote servers are delivered to sandboxes as authenticated Roomote proxy URLs (/api/mcp/custom/<id>); the proxy injects credentials per request, so header values and OAuth tokens never enter sandbox-readable config or the browser.
• OAuth per the MCP authorization spec: RFC 8414/9728 discovery, RFC 7591 Dynamic Client Registration with PKCE, manual client id/secret fallback for servers without DCR, RFC 8707 resource indicators (with a per-server opt-out), server-side token refresh, and an explicit reconnect state when a refresh is definitively rejected.
• Local (stdio) servers, launched inside the task sandbox via the same pipeline as environment-scoped mcpServers (inheriting the reserved-env-reference defenses and the mise shim fix). Env values are encrypted at rest and write-only in the UI.
• Per-tool deny lists, enforced at the proxy (tools/call blocked, tools/list filtered), managed from a tool dialog that lists the server's live tools.

Security

• New safeFetch egress guard for all control-plane traffic to operator-supplied URLs (the proxy data path and every OAuth discovery hop, including URLs the remote server itself supplies): private/special-use ranges blocked, DNS answers vetted and pinned (anti-rebinding), redirects refused. Self-hosters can allow specific internal ranges with R_CUSTOM_MCP_ALLOWED_PRIVATE_CIDRS (a CIDR list, deliberately not a boolean).
• Reserved names (roomote, catalog ids, github, slack) and reserved runtime env references are rejected at save time.
• Header names the proxy owns (authorization, host, mcp-session-id, ...) cannot be overridden; header values are validated against CR/LF injection.
• Editing a server's URL or auth mode clears stored OAuth tokens, so credentials can never be replayed against a different endpoint.
• Custom-server secrets are per-value encrypted at rest; list endpoints return key names only; the decrypted stdio config endpoint is restricted to run tokens.
• R_CUSTOM_MCP_DISABLED kill switch, independent of R_CURATED_INTEGRATIONS_DISABLED (operators who disable the catalog are the primary custom-server audience).

Notes

• Deployment servers merge after environment-scoped mcpServers; the more specific scope wins name collisions.
• Custom server names feed the self-setup catalog so the setup agent stops recommending services that are already wired.
• Docs: new integrations/custom-mcp-servers page plus updates to the integrations index and the add-integration skill.
• Rollout note: workers baked into old sandbox snapshots don't fetch custom servers; the feature appears on fresh-snapshot tasks.
• Migration is additive (N-1 safe). OAuth connections reuse mcpConnections under a custom:<serverId> id namespace, which previous-release code ignores.

Testing

• Schema validation, CRUD (encryption round-trip, blank-keeps-existing, token clearing), SSRF guard units (blocked ranges, IPv4-mapped bypasses, DNS pinning against a live local server, redirect refusal), proxy integration tests against a mock MCP server (header injection, OAuth, deny lists, redirect refusal, egress guard, body cap), worker merge/redaction tests, SDK delivery and run-token gating tests, and UI client tests.
• Verified end to end on a dev deployment: server CRUD in Settings, live tool listing through the guard, per-tool disables, and an agent task calling the tools through the proxy.

Screenshots

Custom servers render as ordinary integration cards in the same Connected/Configured grids as the built-in catalog, marked with a small Custom badge. A prompt bar at the top is the entry point for adding one.

Adding a server starts from one dialog that chooses between a remote (HTTP) and a local (stdio) server:

Header auth (values write-only)	OAuth (DCR + manual client fallback)

Local (stdio) config	Per-tool deny list (proxy-enforced)

[roomote-community]

No new code issues found. See task

• Request-size limit is applied after the body has already been buffered and parsed, allowing oversized JSON requests to exhaust API resources.
• Importing mcp-remote Authorization headers produces a static-header configuration rejected on save.

_{Reviewed b9dab52}

[mrubens]

Fixed in 97537bb. The cap was enforced after c.req.json() had already buffered and parsed the body (and JSON.stringify allocated it a second time), so the limit protected nothing.

Capped upstreams now read through readBoundedRequestText, which rejects on Content-Length before touching the stream and then enforces the limit while reading, aborting the moment the accumulated size crosses it. Because Content-Length is absent on chunked bodies and can understate the real size, the streamed bound is the actual control; the header check is just an early exit. The vetted text is forwarded as-is instead of being re-serialized, dropping the second allocation. Uncapped curated proxies keep their existing path.

Covered by three tests: an oversized parsed body, an oversized Content-Length carrying invalid JSON (a 413 rather than a 400 proves the check precedes parsing), and an endless chunked stream with no Content-Length that aborts well before exhausting memory.