Feature request: Support multiple Slack workspaces in the built-in Slack connector

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/27302
2. https://github.com/anthropics/claude-code/issues/39952
3. https://github.com/anthropics/claude-code/issues/36024

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Found 3 possible duplicate issues: 1. [[FEATURE] Support multiple Connector accounts (same connector, different accounts) in Claude and Claude Code on the web (claude.ai/code) #27302](https://github.com/anthropics/claude-code/issues/27302) 2. [[FEATURE] Per-project OAuth tokens for project-scoped MCP servers (multi-workspace support) #39952](https://github.com/anthropics/claude-code/issues/39952) 3. Support multiple Gmail accounts in MCP integration #36024 This issue will be automatically closed as a duplicate in 3 days. If your issue is a duplicate, please close it and 👍 the existing issue instead To prevent auto-closure, add a comment or 👎 this comment 🤖 Generated with Claude Code

Not a dupe. This is a distinct issue.

+!

I have a work slack and a home slack, and I'd like my assistant to be able to aggregate information across both when needed.

Yes. I have a fairly similar situation. In this case 1 Pro Max x20 personal claude and slack, and 1 Claude and 1 Slack from my company. Even if I could just have each communicate with the corresponding slack with an easier way to sign into my different versions of Claude, it would be amazing.

+1

+1. Many companies have multiple slack workspaces and then add to them many attached customer/partner workspaces!

+1 - this seems like a very common usecase

I also have this use case - +1

+1

Also looking forward to this! +1

+1

+1

+1

+1
Linear, Google, ... please support multiple workspaces for other apps as well

+1

+1

+1 I have multiple use cases for this

• A company buys another company, it takes time for tool consolidation, during that time, there are multiple workspaces under the current company
• Being a part of community groups as well as corporate groups. e.g., running a meetup, a learning group, etc.
• vendors and partners often use Slack Connect or are invited to a specific channel in their Slack.

Workaround for Slack Enterprise Grid customers: Slack Grid seems to grant access to channels across companies after they are enrolled in Slack Grid. The big caveat here is that it has to take months or longer to migrate, or there is never a migration option.

Partner/Vendor workaround: Slack Connect works, but not all partners or vendors use it. I don't have a current example to test the simple invite at the moment.

Concerns

Many organizations won't want data to be shared from corporate Slack to personal or community Slack. Ideally, there is control for multi-tenant situations. Maybe as simple as requiring permission to share between Slack Organizations that are not part of Grid.

+1

+1

+1

+1

+1

+1

+1

+1 with a longer note than usual — I went deep on this trying to ship a plugin that bundles two Slack workspaces, and want to share the failure modes I hit and a concrete API proposal, in case it's useful as you scope the fix.

What I tried

Plugin .mcp.json shipping two entries pointing at Slack's hosted MCP, one per workspace:

{
  "mcpServers": {
    "workspace-a-slack": {
      "type": "http",
      "url": "https://mcp.slack.com/mcp",
      "oauth": { "clientId": "...", "callbackPort": 3118 }
    },
    "workspace-b-slack": {
      "type": "http",
      "url": "https://mcp.slack.com/mcp",
      "oauth": { "clientId": "...", "callbackPort": 3118 }
    }
  }
}

Two distinct walls hit, in order.

What it looks like when it works

Once both servers are wired through the workarounds below, the experience is exactly what you'd want — a single Claude Code session can read and write across workspaces in one turn:

❯ Get the last message from the #random channel in each of my Slack connections

  Called Slack, plugin:<plugin>:workspace-b-slack, plugin:<plugin>:workspace-a-slack 6 times (ctrl+o to expand)

⏺ Last message in #random from each workspace:
  - workspace-a-slack (plugin) — Person A: "<greeting>" [2026-06-02 11:40 -03]
  - workspace-b-slack (plugin) — Person B: "<operational note>" [2026-05-25 13:02 -03]

So the underlying capability is already there at the MCP layer — two Slack connections coexisting in one session, distinct tool prefixes, separate OAuth tokens. The missing pieces are entirely on the Claude Code side: deduping by URL inside a plugin, and not exposing a way to pin the OAuth workspace.

Wall 1 — intra-plugin URL deduplication

The second entry is silently suppressed:

MCP server "workspace-b-slack" skipped — same command/URL as server provided by plugin "<plugin>"

Issue #32549 confirms this is intentional for plugin-provided servers. The dedup appears to compare URLs as literal strings — I confirmed empirically that adding a distinguishing query parameter (https://mcp.slack.com/mcp?team=<id>) bypasses it. Slack's MCP server ignores the unknown param, so the connection works.

This is a usable workaround but undocumented behavior to rely on. A future release that normalizes URLs before comparison (which would be the correct behavior for dedup) would silently break every plugin doing this.

Wall 2 — no way to pin the OAuth workspace

Even with both servers connected, the OAuth flow has no workspace constraint. When a user OAuths workspace-b-slack, Slack's consent screen lets them pick any workspace they're a member of. Mis-clicks are easy and the resulting tools talk to the wrong Slack.

Slack's documented mechanism is the team query parameter on the authorize URL, which pre-pins (and effectively forces) the workspace. But:

• oauth.team in .mcp.json is silently ignored — not in the schema.
• The oauth block's documented fields are clientId, callbackPort, scopes, authServerMetadataUrl. None lets you inject arbitrary query params into the authorize URL.
• The MCP URL query string (the wall-1 workaround) doesn't propagate — it's stripped after the initial connection, never reaches the OAuth authorize URL.

The only workaround I found is hosting a custom OAuth server metadata JSON, pointing authServerMetadataUrl at it, and pre-baking the team=... into the authorization_endpoint field. Something like:

{
  "issuer": "https://slack.com",
  "authorization_endpoint": "https://slack.com/oauth/v2_user/authorize?team=<id>",
  "token_endpoint": "https://slack.com/api/oauth.v2.user.access",
  ...
}

This relies on Claude Code preserving the query string when constructing the OAuth redirect URL. Whether it does is undocumented. If/when that behavior changes, OAuth still succeeds but the workspace pin silently fails — the worst-possible failure mode, since teammates would auth to the wrong workspace without realizing it.

Proposal — oauth.authorizeParams (or similar)

A small additive field that hands the bundle through to the authorize URL:

{
  "mcpServers": {
    "workspace-a-slack": {
      "type": "http",
      "url": "https://mcp.slack.com/mcp",
      "oauth": {
        "clientId": "...",
        "callbackPort": 3118,
        "authorizeParams": { "team": "T_AAAAAAAA" }
      }
    }
  }
}

This is provider-agnostic and unlocks a lot beyond Slack:

• Slack: team for workspace pinning
• Google: hd to restrict to a Workspace domain, login_hint for account pin, prompt=select_account for explicit account picker
• GitHub: login for account hint, allow_signup=false
• Microsoft: tenant for AAD pin
• Generic: anything custom an enterprise auth server expects

It also fixes the deeper problem behind this issue: the missing primitive isn't really "multi-workspace Slack," it's "plugin-shipped MCP entries can't differentiate themselves at the OAuth-authorize layer." Once that primitive exists, the dedup issue could also be relaxed (two entries with same URL but distinct authorizeParams are clearly not duplicates).

Happy to test a beta build if useful — currently running the authServerMetadataUrl workaround in a small private deployment and would gladly switch to a proper API.

+1

+1

This is a blocker

+1

+1

Yes, I have an operations agency that is a part of several slack workspaces. if i could have claude read through them that would be game changing!!