Notion connector tools remain 401 after reconnect in Codex desktop

Additional finding after trying CLI MCP login:

I ran:

codex mcp login notion

The CLI flow opened the Notion OAuth URL and completed successfully:

Successfully logged in to MCP server 'notion'.

However, in the Codex Desktop conversation, tool discovery still exposes Notion as:

mcp__codex_apps__notion

and calling fetch still returns:

401: "Server returned 401: 'Reauthentication required'"

So the successful CLI MCP login does not appear to refresh or affect the Desktop app's current Notion connector/tool runtime. The Desktop session also does not expose a usable mcp__notion__ namespace after CLI login; it continues to route through the Codex Apps connector namespace.

This suggests there may be two separate auth/runtime paths:

1. CLI MCP server auth: codex mcp login notion succeeds.
2. Desktop Codex Apps connector auth: mcp__codex_apps__notion remains unauthenticated and returns 401.

It would help if Codex Desktop either:

• picked up CLI MCP auth for the configured MCP server,
• exposed the CLI notion MCP server as a separate active MCP server after login,
• or clearly showed that the Desktop connector is a separate auth path requiring separate reauthentication.

User experience / frustration feedback:

This is extremely frustrating from a user perspective. The user simply wanted to use the Notion MCP from Codex Desktop, but the path to get a basic MCP working is unclear and surprisingly hard.

What makes this confusing:

• The UI shows notion under plugins / connectors, but the active MCP server list does not clearly show whether Notion is installed, authenticated, enabled, or available to the current session.
• codex mcp login notion succeeds in the terminal, but Codex Desktop still calls mcp__codex_apps__notion and returns 401. There is no obvious indication that these are separate auth/runtime paths.
• The user cannot tell whether they should authorize via Codex Desktop UI, via CLI, via MCP server settings, or via the plugin connector.
• After reinstall/reconnect/login, the current Desktop session still does not refresh into a usable state.

The user also asked Codex to operate the Codex UI directly to fix the setup, but Computer Use refuses to control com.openai.codex:

Computer Use is not allowed to use the app 'com.openai.codex' for safety reasons.

That leaves the user stuck in a loop: Codex can diagnose that the Notion tool is unauthenticated, but cannot operate its own settings UI to resolve it, and the UI/CLI do not provide a clear single source of truth for auth state.

Expected product behavior:

• MCP/plugin status should clearly show: installed, connected, authenticated, needs reauth, active in current session, or requires restart.
• If CLI auth and Desktop connector auth are separate, the product should say so explicitly.
• If a current session cannot pick up newly authenticated MCP state, Codex should say exactly: "restart required" or provide a "refresh MCP auth" action.
• If Computer Use cannot operate Codex itself, there should be another supported self-diagnostic / repair path for Codex settings.

The current experience makes a basic MCP setup feel unreliable and opaque.

Final follow-up / confirmed workaround:

After running:

codex mcp login notion

and then restarting Codex Desktop, the Desktop session finally exposed both tool namespaces:

mcp__codex_apps__notion
mcp__notion__

Calling mcp__notion__.notion_fetch then successfully fetched the target Notion page.

So a likely workaround is:

1. Run codex mcp login notion in the terminal.
2. Complete the browser OAuth flow.
3. Restart Codex Desktop.
4. Use the newly exposed mcp__notion__ namespace, not mcp__codex_apps__notion.

This confirms the user-facing problem: there is no clear indication that CLI MCP login requires a Desktop restart before the server/tool namespace becomes available inside the Desktop conversation. The user only discovered this by trial and error.

It is also still unclear whether the successful result was caused by CLI auth, Desktop restart, connector refresh, or some combination. These actions happen across different surfaces (terminal CLI vs Desktop app UI), but the product gives no explicit explanation of how they relate.

From a UX standpoint this is still very poor:

• The user sees Notion in Desktop plugins/connectors, but the usable tool after the workaround is a different mcp__notion__ namespace.
• Before restart, tool discovery exposed only the connector path and it stayed 401.
• After restart, the CLI-authenticated MCP server appeared and worked.
• There is no prompt saying "restart Codex Desktop to load this MCP login".
• There is no clear single source of truth showing whether the Desktop connector or CLI MCP server is active.

Suggested improvement:

• After codex mcp login <server>, show whether Desktop needs restart.
• In Desktop MCP settings, distinguish CLI MCP servers from Codex Apps connectors.
• If a newly authenticated MCP server is not loaded into the current Desktop session, show "restart required" or provide a "reload MCP servers" button.
• In tool discovery/errors, indicate which auth path is being used: CLI MCP server vs Codex Apps connector.

Seems related to https://github.com/openai/codex/issues/24675

I am seeing a related failure earlier in the OAuth flow on macOS with Codex Desktop and codex-cli 0.146.0.

The Notion plugin/connector path and the official remote-server configuration both fail. codex mcp get notion reports the server as enabled with streamable HTTP at https://mcp.notion.com/mcp.

When I run codex mcp login notion, the browser opens https://mcp.notion.com/authorize?..., but then ends on a normal https://app.notion.com/p/<redacted> workspace page with no consent UI. The OAuth connection never becomes usable.

This differs from the 401-after-reconnect symptom in this issue, but may be the same plugin/OAuth/MCP handoff failure. Reinstalling/reconnecting the plugin and using the CLI setup both reproduce it. OAuth URL parameters and any credentials have been omitted.