Skip to content

Codex Desktop Slack connector keeps stale OAuth link after revoke/reconnect; no reliable hot-swap path for multi-Slack users #19669

Open
Open
Codex Desktop Slack connector keeps stale OAuth link after revoke/reconnect; no reliable hot-swap path for multi-Slack users#19669
Labels
appIssues related to the Codex desktop appauthIssues related to authentication and accountsbugSomething isn't workingtool-callsIssues related to tool calling

Description

@MJWNA
MJWNA
opened on Apr 26, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

26.422.30944

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

Codex Desktop can keep using a stale managed Slack connector OAuth/link state after a user revokes the wrong Slack authorization and reconnects the intended Slack account in ChatGPT Apps.

This makes Slack account switching very difficult for developers who work across multiple Slack workspaces, clients, or businesses. In this case, the only working recovery path required Slack-side revoke, ChatGPT-side disconnect/reconnect, clearing Codex app tool cache, and restarting Codex.

The key symptom was that Codex continued routing Slack tool calls through a stale managed connector link after Slack was revoked/reconnected. The browser-side ChatGPT UI could show Slack as connected while Codex tool calls still failed.

Observed errors during recovery:

HTTP 401: invalid_token

After ChatGPT Settings -> Apps -> Slack -> Disconnect -> Connect, the running Codex session then changed to:

Unknown tool: slack_slack_read_user_profile
Unknown tool: slack_slack_search_channels

Only after moving aside the local Codex app tool cache and fully restarting Codex did the Slack tools refresh and start working again.

What steps can reproduce the bug?

  1. In Codex Desktop, install/enable the curated Slack app connector.
  2. Authenticate Slack with the wrong Slack account or workspace.
  3. Attempt to use Slack from Codex. In my case this initially failed for the target private channel because the wrong Slack identity was connected.
  4. Revoke the wrong Slack authorization from Slack's app authorization/configuration page.
  5. Attempt to use Slack from Codex again.
  6. Observe Codex Slack tools fail with:
HTTP 401: invalid_token
  1. Reconnect Slack from the browser / ChatGPT app connector UI.
  2. Observe ChatGPT web can show Slack as connected, but Codex Desktop still fails because its managed connector/tool state is stale.
  3. In one recovery attempt, ChatGPT-side reconnect changed the Codex error from invalid_token to:
Unknown tool: slack_slack_read_user_profile
  1. Move aside the local app-tool cache:
mv ~/.codex/cache/codex_apps_tools ~/.codex/cache/codex_apps_tools.bak
  1. Fully quit and reopen Codex Desktop.
  2. Slack tool calls finally refresh and work again.

During debugging, the local tool cache repeatedly regenerated with the same stale Slack connector/link identity. Exact connector/link IDs are omitted from this public report but can be provided privately if useful.

What is the expected behavior?

Codex Desktop should provide a clear, reliable way to:

  • disconnect a managed app connector,
  • revoke or forget the current connector link,
  • force fresh OAuth,
  • hot-swap between Slack identities/workspaces,
  • refresh the local tool registry without requiring manual filesystem cache moves.

Codex should not continue routing managed Slack tool calls through a stale revoked connector link after reconnect.

When a managed connector returns invalid_token, Codex should guide the user to re-authenticate or automatically invalidate the stale local/remote connector state. The UI should not leave the user in a state where ChatGPT says Slack is connected but Codex tool calls still fail.

Additional information

Workaround found:

  1. In ChatGPT web: Settings -> Apps -> Slack -> Disconnect.
  2. Reconnect Slack and approve OAuth for the intended Slack workspace/account.
  3. Quit Codex fully.
  4. Move aside:
~/.codex/cache/codex_apps_tools
  1. Reopen Codex.
  2. Verify Slack tools with slack_read_user_profile and slack_search_channels.

Business / adoption impact:

This is a retention and adoption risk for developers and teams that rely on Slack as their primary operational channel. Many developers work across multiple businesses, agencies, clients, or internal/external Slack workspaces. If Codex cannot reliably hot-swap or reset Slack connector OAuth, users may lose trust in Codex for day-to-day engineering workflows and fall back to competing coding agents that make account switching clearer.

For teams evaluating Codex, connector reliability is part of the product's credibility. A confusing or fragile OAuth recovery path can block rollout even if the core coding experience is strong.

Suggested fixes:

  • Add a Codex Desktop UI action to disconnect/reconnect managed app connectors directly from Codex.
  • Add a "forget connector OAuth/link and refresh tools" action.
  • Add CLI support for managed Codex app connectors, such as codex apps logout slack / codex apps login slack.
  • Automatically invalidate stale connector/tool state when a managed app connector returns invalid_token.
  • Support explicit Slack workspace/account selection or hot-swap for users with multiple Slack accounts.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    authIssues related to authentication and accounts
    tool-callsIssues related to tool calling
    on Apr 26, 2026

  2. github-actions commented on Apr 26, 2026

    @github-actions
    github-actionsBot
    on Apr 26, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. tonyholmes69 commented on May 6, 2026

    @tonyholmes69
    tonyholmes69
    on May 6, 2026

    Also logged in app on ID: 4bb823c2-e534-45a2-891d-e04ba05ed7c4

    Gmail plugin also exhibits the same Oauth behaviour ... uninstalling and reinstalling fails to initiate Oauth reauthentication and uses cached credentials. As of this moment I see no way to change accounts on Gmail connector once authenticated.

  4. gabrieljobs-nc commented on Jul 16, 2026

    @gabrieljobs-nc
    gabrieljobs-nc
    on Jul 16, 2026 – with ChatGPT Codex Connector

    I reproduced this again on 2026-07-16, and the documented cache/restart workaround no longer recovers the connector.

    Environment:

    • Codex Desktop 26.707.72221 (build 5307)
    • bundled/system codex-cli 0.144.2
    • Slack connector plugin 0.1.4

    The Slack app settings currently show Disconnected, but a fresh slack_list_workspaces invocation is still routed through the previous managed connector link and returns:

    error_code: UNAUTHORIZED
action: TRIGGER_REAUTHENTICATION
reason: oauth_token_response_invalid

    Recovery attempts already exhausted:

    • local connector/tool cache regeneration 3x
    • reauthorization of the existing connection
    • full disconnect followed by a new Slack OAuth flow
    • two full Codex/ChatGPT restarts
    • two plugin appserver restarts

    Across 19 connector invocations, 18 returned the same OAuth error and one hit an MCP startup timeout. The regenerated cache continued to resolve the same stale managed link.

    This is independent of a receiver bot and its xoxb- token. Adding bot scopes cannot affect the connector platform's authorization-code callback, PKCE exchange, token parsing, principal binding, or server-side link persistence.

    There was also a principal mismatch: the Slack identity selected during reauthorization did not match the owner metadata retained by the managed link.

    The backend should inspect at least these paths:

    1. Disconnect/link lifecycle: disconnect must deactivate or delete the server-side link so invocation cannot resolve it. Reconnect should allocate a new link, or atomically rebind the old link under a new auth revision.
    2. Credential replacement/cache invalidation: a successful callback should replace credentials and invalidate link/resource/tool caches keyed by the old auth revision in one operation.
    3. Slack token-response mapping: for a combined bot + user grant, Slack returns the bot token at top-level access_token and the user token at authed_user.access_token. A user-search connector must persist and invoke with the nested user token. See Slack's OAuth response documentation.
    4. Principal consistency: if authed_user.id changes, do not retain the old link owner/session resources.
    5. Post-callback verification: run a scope-independent slack_list_workspaces smoke call through the normal credential-resolution path before showing the connector as connected.
    6. Diagnostics: preserve a safe Slack error category (for example redirect/PKCE/token-field failures) instead of reducing every token-endpoint response to oauth_token_response_invalid.

    Suggested regression coverage:

    • disconnect prevents resolution of the old link
    • reauthorize increments auth revision and invalidates caches
    • reconnect under a different Slack user cannot reuse the old owner
    • combined bot/user OAuth responses select authed_user.access_token
    • post-auth slack_list_workspaces succeeds through the production resolution path

    I have the exact connector ID, link ID, and UTC reproduction timestamp available for a private support/backend lookup; I am intentionally omitting them here. No OAuth codes, tokens, PKCE verifier, client secret, or user PII were captured.

  5. carl-distill commented on Aug 1, 2026

    @carl-distill
    carl-distill
    on Aug 1, 2026

    This is broken for me and I have no idea how to recover :(

  6. ewcolling commented on Sep 10, 2026

    @ewcolling
    ewcolling
    on Sep 10, 2026 – with ChatGPT Codex Connector

    2026-09-10: reproduced on Windows after reconnect, full restart, and a fresh task

    I am seeing the same failure class in Codex Desktop 26.903.8094.0 on Windows 11 Pro 10.0.26200 x64.

    Current sanitized control matrix:

    • Slack is present in the app registry and its permissions are readable, but a fresh workspace-enumeration call fails before workspace or OAuth evaluation with: 
      MCP error: -32001: Unknown tool({"name":"slack.slack_list_workspaces"})
    • HighLevel is also present and its permissions are readable, but a fresh search call fails with: 
      MCP error: -32001: Unknown tool({"name":"highlevel.search"})
    • Stripe tools execute successfully in the same fresh task, so the shared Apps bridge is not completely unavailable.
    • Both failing tool descriptors are advertised/discoverable to the task; the failure occurs only when the live backend dispatches the runtime tool name.

    Recovery already tried:

    1. Disconnect/delete and reconnect the affected apps.
    2. Complete OAuth again.
    3. Fully close and reopen Codex.
    4. Retry from a fresh task.

    The result is unchanged. Because two unrelated connectors fail with the same -32001 Unknown tool result while Stripe works, this looks like stale or missing server-side tool registration/capability mapping rather than a user authorization or connector-permission problem.

    Could the connector team please check registry publication/invalidation and wrapper-to-runtime mappings for the Slack and HighLevel app IDs associated with this session? A safe refresh/repair action in the Codex UI would also be valuable. Connector/link identifiers and exact UTC reproduction times can be provided through a private support channel if needed.

    No workspace names, account IDs, channel data, OAuth material, or credentials are included here.

  7. thnk2wn commented on Sep 11, 2026

    @thnk2wn
    thnk2wn
    on Sep 11, 2026

    Reproduced on macOS in Codex Desktop on September 11, 2026 (UTC), using the managed Slack plugin.

    A read-only slack_slack_read_list call repeatedly produces the UI message “Your Slack connection has expired. Reconnect it before ChatGPT can use it for this request.” After reconnecting, the tool returns:

    Authentication for Slack was requested and accepted. Retry this tool call now.

    The result has isError: true. A subsequent read immediately requests reconnect again. Repeated reconnects and a full quit/reopen of Codex did not recover access. Slack itself remains accessible in its desktop and browser clients, although that does not establish the health of the separate connector credential.

    Local desktop logs confirm accepted mcpServer/elicitation/request responses at 03:12:12 UTC before the full app restart and at 03:17:04 and 03:18:21 UTC afterward. Following the 03:12 acceptance, codex_apps, node_repl, and cua_repl restart and report ready. The available logs/tool results do not expose an underlying Slack HTTP response, missing_scope, or invalid_auth error, so we cannot establish the root cause or confirm that this is the same stale-link mechanism.

    Separately, the advertised list read/update tool descriptions refer to slack_add_list_record and slack_update_list_record, but those row-editing tools are absent from the tools exposed to this task, including after the restart. List creation, reading, and schema/metadata update tools are advertised. This may be a distinct capability-publication issue.

    Impact: maintaining an existing collaborative feedback list requires UI automation because connector reads never recover and row-update tools are not exposed. Repeated reconnect prompts also interrupt the task and reset tool sessions.

    Could the connector team investigate the post-reconnect credential resolution and provide a safe diagnostic error category or repair path? We have stopped retrying to avoid sending the user through further authentication loops.

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

    appIssues related to the Codex desktop appauthIssues related to authentication and accountsbugSomething isn't workingtool-callsIssues related to tool calling

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions