OpenClaw Main Adds Per-Requester OAuth for MCP Tools in Shared Channels

OpenClaw has merged per-requester OAuth for MCP servers into main. A shared bot can now let each trusted sender connect their own account instead of executing every MCP tool call with the operator’s token.

This is an important identity boundary, not a default migration. Existing MCP servers remain in shared-credential mode unless an operator explicitly configures per-requester identity, and the feature has sharp deployment and trust requirements.

The old default was one credential owner

Before PR #122166, every sender in a shared channel reached an MCP server through the operator’s OAuth credentials or a plugin-resolved connection. That can be correct for a deliberately shared service account, but it is wrong when tools should act as the human requester.

The new server option is:

mcp:
  servers:
    example:
      oauth:
        identity: per-requester

The existing shared mode remains the default. That avoids silently changing access, but it also means an upgrade alone does not fix over-broad tool identity.

What per-requester mode changes

For an authenticated channel sender, OpenClaw derives a requester-specific OAuth store from channel, account and sender identity. Each requester receives independent registration, token and lease state. A sender who has not connected gets a sign-in result rather than another person’s data.

The Gateway also gains an MCP OAuth callback route. Operators must configure a valid gateway.publicOrigin; Doctor warns when per-requester mode lacks it. Pending authorization survives restart, successful completion consumes its state, and replay or unknown state returns an expired result.

Per-requester servers fail closed where trusted requester identity is absent. They are excluded from static and scheduled runtimes rather than falling back to the operator token.

Interpretation: this is the critical invariant. An identity-aware tool must refuse work when identity disappears; falling back to a shared credential would turn a missing fact into an authority escalation.

The sign-in link is visible in the shared channel

The merged design returns the authorization URL in the tool result, with a portable connect button where the channel supports one. Upstream maintainers explicitly accepted that tradeoff for the first version because per-requester mode is limited to an operator-curated, mutually trusted roster.

The link is single-use, a newer authorization attempt supersedes an older one, and clicking it binds the clicker’s account to the requester’s row rather than exposing an existing token. Even so, it is state-bearing material delivered into shared conversation history.

Do not enable this mode in a public room, a channel with untrusted readers, or anywhere message archives are broadly exported. A private handoff is tracked upstream as follow-up work; it is not part of this merge.

Important first-version limits

The primary source names several exclusions:

• CLI-runtime bearer projection remains operator-only;
• Control UI management of requester principals is not included;
• an interrupted tool turn does not automatically resume after OAuth completion;
• Codex dynamic tools receive a text URL rather than the channel button;
• openclaw mcp login/logout does not manage requester principals; and
• plugin resolver contracts are not converted automatically.

A sender should expect to authorize, then send another message so the tool catalog can be retried.

Rollout checklist

1. Decide which MCP servers are genuinely user-delegated and which intentionally use a service account.
2. Enable per-requester only for curated shared channels with stable, trusted sender identity.
3. Set gateway.publicOrigin to the exact externally reachable origin; terminate TLS correctly and avoid callback rewriting.
4. Run Doctor and treat a missing-origin warning as a deployment blocker.
5. Test two synthetic users with mutually exclusive server-side records; each must see only their own data.
6. Restart between authorization start and callback, then prove correlation survives once and replay fails.
7. Test an unidentified sender, a scheduled run and a static runtime; all must fail closed without borrowing the operator token.
8. Review channel retention, exports and bot visibility because authorization links appear in conversation.
9. Document the second-message requirement after sign-in and the lack of requester CLI logout in this version.

Evidence and limits

The upstream PR reports 407 grouped tests plus a two-user end-to-end run against a self-hosted standard MCP OAuth server. That proof asserted distinct requester stores and tokens, cross-user data isolation, restart survival, callback replay rejection and an unconnected third-sender negative case. OpenClaw Academy reviewed the primary source and merged commit chronology but did not connect a live customer MCP server.

Relevant collector records are 52563, 52655 and 52689.

Bottom line

Per-requester OAuth fixes a real authority problem for shared bots, but only when operators choose it deliberately. Keep service-account tools on shared mode, use requester mode only with trusted sender identity, protect the callback origin, and treat the channel-visible sign-in link as an explicit security tradeoff—not harmless UI chrome.