claude-code - 💡(How to fix) Fix Slack MCP tools silently deactivate mid-session (~1h uptime); claude mcp list still reports Connected [3 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#60428Fetched 2026-05-20 03:58:49
View on GitHub
Comments
3
Participants
3
Timeline
9
Reactions
1
Author
Timeline (top)
commented ×3cross-referenced ×3labeled ×3

Slack MCP tools (slack_send_message, slack_search_channels, etc.) reliably work at the start of a Claude Code session, then after roughly an hour silently disappear from the model's deferred-tool registry — with no app restart, no plugin reinstall, no OAuth re-auth, and no config change on the user side. Crucially, claude mcp list continues to report ✓ Connected after the tools vanish, so neither the user nor the assistant can tell from the obvious surface that anything has dropped.

The recurring user-facing failure mode is: the assistant tries to invoke a Slack tool, gets a missing-tool result, then frequently misdiagnoses by suggesting the Slack Connector "isn't installed" — even though it has been installed all along and the same Connector was working tool-calls minutes earlier in the same session.

Root Cause

Reproduction

  1. Start a Claude Code session with Slack tools working — verify by sending a test Slack message via slack_send_message.
  2. Continue using Claude Code on unrelated work for ~1 hour (no Slack activity needed).
  3. Attempt another Slack tool call (e.g. via an end-of-MR Slack post flow).
  4. Tool call fails because the tool is no longer in the deferred-tool list.

Fix Action

Fix / Workaround

Workarounds (in observed order of reliability)

  • Open a new chat in the same Claude Code window. Confirmed to re-bind tools in the original session without losing context — verified 2026-05-19. Mechanism unclear.
  • Toggle the Slack Plugin off → on in Customize → Personal plugins. Re-binds in the same session, no restart, no context loss. Works sometimes; did not work in the 2026-05-19 occurrence where the new-chat trick succeeded.
  • App restart. Works, but loses the session.
  • /clear. Works (forces a system-prompt rebuild that re-reads the tool catalog), but nukes conversation context — not a real fix.

Code Example

$ claude mcp list
Checking MCP server health…
plugin:slack:slack: https://mcp.slack.com/mcp (HTTP) -Connected
RAW_BUFFERClick to expand / collapse

Summary

Slack MCP tools (slack_send_message, slack_search_channels, etc.) reliably work at the start of a Claude Code session, then after roughly an hour silently disappear from the model's deferred-tool registry — with no app restart, no plugin reinstall, no OAuth re-auth, and no config change on the user side. Crucially, claude mcp list continues to report ✓ Connected after the tools vanish, so neither the user nor the assistant can tell from the obvious surface that anything has dropped.

The recurring user-facing failure mode is: the assistant tries to invoke a Slack tool, gets a missing-tool result, then frequently misdiagnoses by suggesting the Slack Connector "isn't installed" — even though it has been installed all along and the same Connector was working tool-calls minutes earlier in the same session.

Environment

  • Claude Code version: 2.1.142
  • OS: Windows 10/11 (PowerShell + Git Bash)
  • Slack Plugin: installed (slack@claude-plugins-official: true in ~/.claude/settings.json)
  • Slack Connector: installed (Directory → Connectors → Slack)
  • Endpoint reported by both paths: https://mcp.slack.com/mcp

Reproduction

  1. Start a Claude Code session with Slack tools working — verify by sending a test Slack message via slack_send_message.
  2. Continue using Claude Code on unrelated work for ~1 hour (no Slack activity needed).
  3. Attempt another Slack tool call (e.g. via an end-of-MR Slack post flow).
  4. Tool call fails because the tool is no longer in the deferred-tool list.

Probing in the broken state:

$ claude mcp list
Checking MCP server health…
plugin:slack:slack: https://mcp.slack.com/mcp (HTTP) - ✓ Connected

ToolSearch for any prefixed slack_* tool returns No matching deferred tools found despite the ✓-Connected status.

Expected

Either:

  • the MCP list_changed notification path rebinds the Slack tools into the session's tool catalog when they come back, OR
  • claude mcp list and any user-visible status surface reflect that the tools are de facto unavailable (so users and assistants don't mis-diagnose).

Actual

Tools silently leave the deferred-tool list. claude mcp list keeps reporting ✓ Connected. There is no in-session surface that says "Slack tools dropped at <time> — restart to recover".

Workarounds (in observed order of reliability)

  • Open a new chat in the same Claude Code window. Confirmed to re-bind tools in the original session without losing context — verified 2026-05-19. Mechanism unclear.
  • Toggle the Slack Plugin off → on in Customize → Personal plugins. Re-binds in the same session, no restart, no context loss. Works sometimes; did not work in the 2026-05-19 occurrence where the new-chat trick succeeded.
  • App restart. Works, but loses the session.
  • /clear. Works (forces a system-prompt rebuild that re-reads the tool catalog), but nukes conversation context — not a real fix.

What does NOT restore them

  • /mcp, /compact, /resume, /config
  • Waiting

Hypothesis

OAuth state at mcp.slack.com/mcp appears to drift, and the client's deferred-tool registry has no refresh trigger short of a full system-prompt rebuild (which is why /clear works). The MCP list_changed notification path that should handle this evidently isn't firing — or isn't being honored — for the Slack Connector after the silent drop. Both the Plugin path and the Connector path appear to suffer from this; in this user's installation it has recurred across many sessions over months.

Secondary issue (UX)

When this happens, the assistant — guided by current docs and skill prompts — often suggests "install the Slack Connector" as the remediation. That's wrong: the Connector is already installed, it was working in this session, and the suggestion sends users on a 30-second wild goose chase before they realize the real fix is restart / new chat / plugin toggle. A clearer "Slack tools are no longer bound in this session — restart Claude Code or open a new chat to recover" message would prevent this misdiagnosis loop.

Asks

  1. Surface the deactivation in claude mcp list (or somewhere user-visible) so this stops being silent.
  2. Wire the list_changed notification — or some periodic resync — so Slack tools can come back without /clear or a new chat.
  3. Update assistant-facing docs/skills to recommend restart / new chat / plugin toggle, not Connector reinstall, when Slack tools go missing mid-session

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING