›_ Codex Issues
Codex Issues / #19669

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

Open 💬 4 comments Opened Apr 26, 2026 by MJWNA
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

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

  • #19489
  • #18603

Powered by Codex Action

tonyholmes69 · 3 months ago

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.

gabrieljobs-nc · 1 month ago

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.

carl-distill · 26 days ago

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