Skip to content

Notion connector tools remain 401 after reconnect in Codex desktop #24848

Open
Open
Notion connector tools remain 401 after reconnect in Codex desktop#24848
Labels
bugSomething isn't working

Description

@Nomia
Nomia
opened on May 28, 2026

Summary

The Codex desktop app can discover Notion connector tools after reinstall/reconnect, but the tools still fail with 401 Reauthentication required. The UI does not make it clear whether Notion is installed, authenticated, enabled as an MCP server, or only available as a plugin connector.

Environment

  • Codex desktop app on macOS
  • Date observed: 2026-05-28
  • Notion plugin/connector was uninstalled, reinstalled, and reconnected by the user
  • Screenshot state: notion appears under "From plugins", while the main MCP server list only shows node_repl and playwright

Expected behavior

After reconnecting / reauthorizing Notion, the current Codex session should be able to use the Notion tools to fetch and update pages.

Actual behavior

Tool discovery exposes Notion tools under:

mcp__codex_apps__notion

But fetching a Notion page still fails:

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

The older mcp__notion__ namespace is no longer usable in this session:

unsupported call: mcp__notion__notion_fetch

Steps tried

  1. Uninstalled the Notion MCP/plugin from Codex settings.
  2. Reinstalled / reconnected Notion.
  3. Retried tool discovery.
  4. Retried mcp__codex_apps__notion._fetch against a Notion page URL.
  5. Still received 401 Reauthentication required.

Impact

  • Codex can discover Notion tools but cannot actually read or write Notion pages.
  • Reinstalling/reconnecting Notion does not appear to refresh the connector auth state available to the current Codex runtime.
  • The UI does not clearly distinguish:
    • installed plugin
    • connected OAuth account
    • active MCP server
    • connector requiring reauthentication

Requested improvements

  • Refresh Notion connector authentication after reconnect/reinstall so the current Codex session can use the tools.
  • Surface explicit status in the MCP/plugin UI: connected, needs auth, enabled as MCP, installed as plugin only, etc.
  • Provide a way to force-refresh connector auth for the current session without guessing whether a Codex restart is required.
  • If a connector is discovered but unusable due to auth, show that status in tool discovery or the tool error with a user-actionable remediation.

Activity

  1. Nomia commented on May 28, 2026

    @Nomia
    Nomia
    on May 28, 2026
    Author

    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.

  2. Nomia commented on May 28, 2026

    @Nomia
    Nomia
    on May 28, 2026
    Author

    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.

  3. Nomia commented on May 28, 2026

    @Nomia
    Nomia
    on May 28, 2026
    Author

    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.

  4. rubyisbeautiful commented on May 28, 2026

    @rubyisbeautiful
    rubyisbeautiful
    on May 28, 2026

    Seems related to #24675

  5. etraut-openai
    added
    bugSomething isn't working
    on May 29, 2026

  6. ErwannRousseau commented on Aug 5, 2026

    @ErwannRousseau
    ErwannRousseau
    on Aug 5, 2026

    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/ 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions