[Fix] Integration guidance and old links still point to Settings > Integrations

[roomote-roomote]

​Created by Roomote. View the task or mention @roomote-roomote for follow-up asks.

Related issue

No linked issue. This is a follow-up to #2937, which moved Integrations out of Settings to a top-level /integrations page.

Why this PR exists

• A maintainer explicitly invited this PR in the linked issue or discussion
• I am a maintainer / this is internal Roomote work

#2937 moved the page and updated the URL builders, but agent prompts, tool descriptions, error messages, UI copy, and docs still sent people to "Settings → Integrations". The old /settings/integrations URL also started returning 404, even though links to it already sit in chat messages, emails, transcripts, and OAuth redirectTo values created before the move.

What changed

Agent replies, error messages, UI hints, and docs now send people to the top-level Integrations page instead of a Settings section that no longer exists. Old /settings/integrations links open the Integrations page instead of a 404. Slack and GitHub setup guidance now points to the Settings pages where those providers are actually configured. The only behavior change beyond copy is the new redirect. Changes by category:

Route. The Integrations page is served at /integrations by apps/web/src/app/(authenticated)/integrations/page.tsx. No legacy redirect existed, so /settings/integrations fell through to the authenticated catch-all and 404'd. This PR adds settings/integrations/page.tsx, reusing the LegacySettingsRedirectPage that /settings/automations already uses. Old links now land on /integrations and keep their query string and hash, such as ?highlight=…, ?service=…, or ?mcp=connected.

Agent and session prompts, tool text, and skills

• Fast system prompt (fast-agent-prompt.ts):
  • The connect_integration guidance now names "the secure form on the Integrations page".
  • Remote MCP guidance now says "Preserve returned authorizeUrl and settingsUrl links exactly".
  • The superseded, currently disabled integration-key guidance now says old keys are revoked on the Integrations page, or under Personal settings for a private key.
• Native tool descriptions:
  • add_remote_mcp previously called its settingsUrl "the existing Settings link". It now says the link goes to the Integrations page for a shared server, or Personal settings for a private one.
  • connect_integration now names "the existing secure form on the Integrations page".
  • The generic Integration settings link label stays, because a private server's link resolves to Personal settings.
• Setup session: the tool-picker options now read "Connect X on the Integrations page.", and the continue option reads "You can connect them later on the Integrations page."
• Setup recommendation catalog (mcp-self-setup/catalog.ts): built-ins now use Integrations > X. Slack now uses Settings > Communications > Slack and GitHub Settings > Source Control > GitHub, because neither is configured on the Integrations page. GitHub previously pointed at an Environments sub-section that no longer exists.
• Worker get_about_me integrations guide (integration-setup.ts):
  • Every built-in integration now points to the Integrations page.
  • Slack and GitHub point to Settings > Communications and Settings > Source Control.
  • The Custom MCP section previously said these servers were environment-only and "not in Settings > Integrations". It now says remote servers can be added from the Integrations page (shared) or Personal settings (private), as well as in environment YAML.
• Skills:
  • feature-demo: the ElevenLabs voice-over note.
  • zero.
  • The repo-local add-integration skill: its catalog description, its custom MCP recommendation, and the setup-guide wording it prescribes for new integrations.

Error and unavailable messages

• API custom MCP proxy: a shared server now "needs to be reconnected by a deployment admin on the Integrations page". Personal servers still point to Personal settings.
• SDK add_remote_mcp name and URL conflict: "Review them on the Integrations page or in Personal settings."
• Web: the Triage Sentry Issues save and run errors ("Configure Sentry on the Integrations page before …") and the error for listing stdio server tools.

UI copy (apps/web)

• API-key integration dialog: "Manage it on the Integrations page, or in Personal settings if you choose Only me."
• Experimental → Integration tool approvals: the Manage tools dialog is now described as "on the Integrations page".
• Automations → Triage Sentry Issues: the toast and helper text.
• Linked Accounts empty state: "Enable a user-linked app on the Integrations page…"
• Session transcript label for add_remote_mcp setup results: now "needs manual setup", previously "needs setup in Settings". The link can go to either page.

Docs (apps/docs)

• 37 pages now say "the Integrations page", or use Integrations > X for nested paths. They cover the integration guides and overview, integration keys, HTTP integrations, custom MCP servers, personal settings, voice, environment variables, and cookbook recipes.
• Automations also moved to a top-level page, so the 11 "Settings > Automations" references across 9 pages now point to the Automations page. Those pages are automations, three cookbook recipes, models, the Slack and Discord providers, and source control.

Comments and tests. Code comments that named the old path are updated. Tests that asserted the old strings are updated. New tests cover the legacy redirect, the worker integrations guide, the setup catalog locations, and the add_remote_mcp tool-presentation label.

Deliberately not changed

• Sections that did not move out of Settings, such as Personal, Skills, Models, and Communications.
• The settingsUrl result field and the SETTINGS_PATHS.integrations constant. Both already resolve to /integrations.
• The generic /settings fallback in the MCP OAuth initiate and callback routes, which predates the move.
• CHANGELOG.md history.
• Two references that are stale for reasons unrelated to this move, left for a separate fix:
  • The compose comments that say to paste the gbrain token into "Settings > Integrations > Brain". There is no Brain connection form anymore.
  • The source-control account-linking message that points to "Settings -> Environments -> Source Control".

How it was tested

• Package test suites for @roomote/types, @roomote/worker, @roomote/sdk, @roomote/api, and @roomote/cloud-agents, plus focused @roomote/web server and client suites for the changed surfaces. One @roomote/cloud-agents test (opencode-runtime plugin seeding) fails in the dev sandbox. It also fails on unmodified develop and is unrelated to this change.
• pnpm lint, pnpm check-types, pnpm knip, and pnpm --filter @roomote/docs check.
• In the local dev app, /settings/integrations?highlight=sentry-mcp redirected to /integrations?highlight=sentry-mcp (screenshots below).

Checklist

• The PR title follows the repo convention: [Fix], [Feat], [Improve], [Refactor], [Docs], or [Chore] followed by a user-facing description
• This PR is small and scoped to one change
  • It is scoped to one change, updating references after the Integrations move, but it touches 85 files. Most edits are one-line copy changes.
• pnpm lint and pnpm check-types pass locally
• I added tests or included a clear manual validation note above
• I removed secrets, tokens, private keys, and customer data from code, logs, and screenshots
• If this change should appear in the changelog, I ran pnpm changeset
  • Added .changeset/integrations-page-references.md (patch).

Screenshots

[roomote-community]

1 issue outstanding. See task

• Update the remaining Brain activation comments in both compose files so they do not contradict Settings > Memory. (deploy/compose/docker-compose.prod.yml:13-16)
• Update the shared Brain contract comment so it does not claim an R_BRAIN_* key is the sole activation signal or point to Integrations. (packages/types/src/brain.ts:7-10)

_{Reviewed fee9216}

[roomote-community]

This comment still says an R_BRAIN_* key alone means the deployment “has a Brain” and that all behavior follows from that one signal. A stored Settings > Memory choice now overrides the legacy key fallback (isBrainEnabled()), so a deployment can have a provider key while Memory is disabled. Please update this comment to describe Memory as the activation control and the key as legacy fallback/provider configuration; it also should not direct readers to the Integrations page.