Docker/headless remote MCP OAuth pairing needs a first-class management flow

[wey-gu]

Summary

Docker/headless self-host users do not have a smooth way to start/manage remote MCP OAuth pairing, because the current flow assumes the Mem server device can open a browser-backed management UI.

Source

Discord Chinese channel, 2026-08-07:

现在怎么从 docker 镜像里触发 mcp 的 oauth 连接？

Current reply/workaround:

• Do not trigger an OAuth browser flow inside a pure Docker/headless container.
• Use a browser on the Mem server device, or open the public HTTPS Mem URL and start the pairing from that management surface.

Product gap

For self-hosted Docker / headless servers, we likely need a first-class pairing-management path, such as:

• a headless-safe pairing command that prints a short-lived browser URL,
• a clear remote management page reachable from the public HTTPS Mem URL,
• better in-app/docs copy explaining where OAuth management must be initiated,
• and explicit failure messages when a user tries to start OAuth from an unsupported container-only context.

This is related to remote MCP OAuth usability, but distinct from the fixed #157 security/origin bug.