> ## Documentation Index
> Fetch the complete documentation index at: https://claude.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshoot Claude Tag setup

> Error messages from Claude Tag setup and what fixes each. Covers permission mismatches, GitHub access gaps, session start failures, and account errors.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

This page covers errors you might hit setting up and administering Claude Tag: Slack app permissions, guest and shared channels, console errors, channels where nothing responds, access and connections, and session starts. Each entry has the same three parts: what you see, what it means, and how to resolve it.

<Note>For problems people can resolve on their own in a channel, like a missing reply or a thread that lost its work, see [Troubleshoot Claude Tag in channels and DMs](/claude-tag/users/troubleshooting).</Note>

If someone reports that Claude can't reach a service you connected, check two things before anything else:

* The connection is in a [bundle attached to that channel's scope](/claude-tag/admins/attach-to-scope).
* The test ran in a new thread; a session loads its connections when it starts, so threads already underway don't see ones added later.

## Slack app permissions

Most errors in this section appear when Claude needs a Slack permission that wasn't part of the app when your workspace approved it. For those, the fix is a Slack workspace admin re-approving the Claude app from [Claude for Slack](https://claude.com/claude-for-slack), which grants the current permission set. Nothing else changes, and existing settings carry over.

### This workspace's Claude app installation is out of date

**What you see**

Claude replies to `@Claude connect`:

> This workspace's Claude app installation is out of date — it hasn't granted the \[permission name] permission(s). I can't create a link code until a Slack admin reinstalls the Claude app or approves its updated permissions. Once that's done, ask me to link again.

Two phrases in the message are links:

* **reinstalls the Claude app** opens the reinstall flow. The fix below starts from this link.
* **approves its updated permissions** opens Slack's Manage apps page for the workspace.

On Enterprise Grid the message names "this Slack organization's Claude app installation" and asks a Slack organization admin to reinstall the org-wide app. The org-wide reinstall works from inside one of the Grid's workspaces with **Install to entire organization**, following the steps in [Claude is silent everywhere on Enterprise Grid](#claude-is-silent-everywhere-on-enterprise-grid).

Sometimes the reply issues a code anyway, with a footnote that the install "is out of date". The reinstall steps below clear the footnote too.

**What it means**

Claude needs a Slack permission that wasn't part of the app when your workspace approved it, so the app was never granted it. Claude can't issue a link code until the updated permission set is approved.

**How to resolve**

A Slack workspace admin runs these three steps:

1. Click the **reinstalls the Claude app** link in the reply, or open [Claude for Slack](https://claude.com/claude-for-slack) and click **Add to Slack**. Don't uninstall first; this installs over the existing app, so your settings carry over.
2. Approve the consent screen Slack shows; it lists each permission being added. If Slack shows **Unapproved permissions requested** instead of completing, see [Unapproved permissions requested](#unapproved-permissions-requested).
3. Run `@Claude connect` again. If the reinstall worked, the reply contains a pairing code (the link code the original message said it couldn't create) instead of this message.

Send that pairing code to whoever runs Claude setup in the console; it expires after 15 minutes. Slack's **Manage apps** page lists the permissions the app requests, not the permissions your workspace has granted, so seeing the missing permission listed there doesn't mean it's approved. The grant happens on the consent screen. For the app's permissions in one place, see [What the Claude Slack app can access](/claude-tag/admins/for-slack-admins).

### Unapproved permissions requested

**What you see**

**Unapproved permissions requested** is a message from Slack, not a Claude reply. It appears in either of two places:

* On the consent screen after **Add to Slack**, including for a workspace admin who approved the app before
* As the pending status on the Claude entry under **Settings & administration** → **Manage apps** → **App requests**, in workspaces that require admin approval for apps

**What it means**

The permissions the Claude app requests have changed since your workspace approved it, and Slack requires a fresh approval for the additions. The consent screen lists each permission being added, so you can review exactly what you're granting before approving; approval applies only to the Claude app already installed in your workspace.

**How to resolve**

A Slack workspace admin approves the Claude app's updated permissions in either place:

* In Slack, go to **Settings & administration** → **Manage apps** → **App requests** and approve the Claude request.
* Or open [Claude for Slack](https://claude.com/claude-for-slack), click **Add to Slack**, and approve the consent screen.

Both paths grant the same permissions, and neither requires uninstalling first.

If the approval worked, `@Claude connect` returns a pairing code without mentioning the installation again.

### Only Slack workspace admins can link this workspace

**What you see**

Claude replies to `@Claude connect`:

> Only Slack workspace admins (or Enterprise Grid org admins) can link this workspace to a Claude organization. Please ask a workspace admin to mention me with `@Claude connect`.

**What it means**

Slack reports that the person who ran `@Claude connect` doesn't hold the workspace admin role, so no pairing code was issued. This reply is itself the signal, and there's nothing else to check. The Claude Owner role doesn't satisfy the check; it's the Slack-side role that matters.

**How to resolve**

Have a Slack workspace admin run `@Claude connect` instead. On Enterprise Grid, a Grid organization admin works too. If the fix worked, their reply contains a pairing code.

### Missing the required Slack permission (users:read)

**What you see**

Claude replies in the channel:

> Claude can't check this channel for guests because it's missing the required Slack permission (users:read). A workspace admin needs to reinstall Claude to grant it.

If the failure happens while Claude is posting a message rather than replying, there's no fixed message; Claude describes the problem in its own words, and the underlying error it relays reads "message not delivered: Claude can't check this channel for guests because the Slack app is missing a permission (users:read); a workspace admin must reinstall Claude to grant it."

**What it means**

**Allow Claude to respond to guests** is set to **Restrict** for this channel's [scope](/claude-tag/concepts/glossary#scope), so Claude checks the channel for guests before replying, and this install predates the `users:read` permission that check needs.

**How to resolve**

Re-approve the app from [Claude for Slack](https://claude.com/claude-for-slack). Don't uninstall first; the re-approval installs over the existing app. If the fix worked, a mention in the affected channel gets a reply instead of the permission message.

## Guest and shared channels

Claude checks a channel for guests and for sharing across workspaces before it replies there, and the refusal messages those checks post look alike. Match the exact message text before changing anything; each comes from a different check with a different fix.

A channel created at the Enterprise Grid organization level rather than inside a single workspace counts as shared across workspaces even when it appears in only one workspace's sidebar, so a channel can hit the shared-channel messages below despite looking like an ordinary single-workspace channel.

### Claude doesn't respond in channels that include guests

**What you see**

Claude replies in the channel:

> Claude doesn't respond in channels that include guests. You can remove the guests from this channel (Channel details -> Members -> filter by "guests"), or a claude.ai organization owner can allow it here.

In the message, "here" is a link to the guest setting described below. The role it names is a claude.ai organization owner, not a Slack admin.

**What it means**

The channel includes at least one Slack guest account, and **Allow Claude to respond to guests** is set to **Restrict** for this channel's scope. **Restrict** is the default.

**How to resolve**

Either fix works:

* Remove the guests from the channel, or move the conversation to a channel with no guests; this changes no settings, so no other channel is affected.
* Or set **Allow Claude to respond to guests** to **Allow** for the scope covering this channel. The setting is at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), on the **Slack** tab under **Claude Tag's access**, in the scope's collapsed **Advanced** section. **Allow** applies to every guest channel that scope covers, and guests there can see Claude's replies and interact with it. To limit it to one channel, set it on the channel's own scope. See [restrict guest channels](/claude-tag/admins/restrict-access#restrict-guest-channels) for the full exposure picture.

If the fix worked, a mention in the channel gets a reply.

### Couldn't check this channel just now

**What you see**

Claude replies in the channel:

> Couldn't check this channel just now. Please try again in a moment.

**What it means**

Claude couldn't complete its check for guests in this channel; either the guest-policy lookup or the Slack membership check briefly failed, so Claude declined this reply rather than risk posting where a guest might see it. This isn't a configuration error.

**How to resolve**

1. Mention Claude again; the retry usually clears it.
2. If one channel hits this repeatedly, the membership check may be failing on an unusually large channel. Setting **Allow Claude to respond to guests** to **Allow** on the channel's scope removes the guest check for every channel that scope covers, which usually stops the message from recurring; weigh [what Allow exposes](#claude-doesnt-respond-in-channels-that-include-guests) first.

### This channel is shared across multiple workspaces

**What you see**

Claude replies in the channel:

> This channel is shared across multiple workspaces, and Claude can't verify whether it includes guests, so Claude can't respond here.

**What it means**

This message comes from the guest check, not from workspace sharing. **Allow Claude to respond to guests** is set to **Restrict** for this channel's scope, and the channel's membership can't be verified, most often because the channel is shared across an Enterprise Grid organization, so Claude declines.

**How to resolve**

Use a channel that belongs to a single workspace. Setting the scope's guest setting to **Allow** removes the guest check that posts this message, but it doesn't guarantee a reply; a channel shared across your Grid's workspaces is separately subject to the refusal in [This channel is shared among several Claude workspaces](#this-channel-is-shared-among-several-claude-workspaces), which no setting lifts.

### This channel is shared among several Claude workspaces

**What you see**

Claude replies in the channel:

> This channel is shared among several Claude workspaces, so Claude cannot respond here.

**What it means**

The channel is shared across more than one Slack workspace in your Enterprise Grid, and Claude doesn't respond in Grid-shared channels regardless of the guest policy or any scope setting. The nearly identical message in [This channel is shared across multiple workspaces](#this-channel-is-shared-across-multiple-workspaces) is the guest case instead.

**How to resolve**

Move the conversation to a channel that belongs to a single workspace, or to a DM.

### This channel is now shared across multiple workspaces

**What you see**

Claude posts in the thread:

> This channel is now shared across multiple workspaces, so this thread's earlier session can't continue here. Please @-mention me in a new thread.

**What it means**

The channel became shared after this thread's session started, so the session is still bound to one workspace's configuration and can't continue in front of every workspace that now sees the channel.

**How to resolve**

Mention Claude in a new thread; new threads start under the channel's current sharing.

## Console errors

### Couldn't load Slack scopes

**What you see**

A banner at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), on the **Slack** tab under **Claude Tag's access**, reads:

> Couldn't load Slack scopes. Reload the page to try again.

**What it means**

The request that loads your scope list from Claude's backend failed; it isn't a Slack permissions problem, and your configuration is intact. The page shows the error instead of an empty list so that a failed load doesn't look like an unconfigured workspace.

**How to resolve**

1. Reload the page. If the reload worked, the scope list renders. That's the usual outcome.
2. If the banner persists across reloads, check [`status.anthropic.com`](https://status.anthropic.com) for an active incident and try again in a few minutes.
3. If it continues with no incident posted, contact [Anthropic support](https://support.claude.com) with the time it occurred.

### The page shows your plan as Free

**What you see**

You open the admin console expecting your organization's settings and land on your personal account settings instead, showing the **Free plan** and no Claude Tag section anywhere.

**What it means**

You're signed into a personal claude.ai account, which is a separate workspace from your organization. claude.ai sends a personal account to its own settings page rather than to the admin console, so the **Free** you see is your personal account's plan, not a broken admin page.

**How to resolve**

Use the workspace switcher in claude.ai to switch to your organization, then reopen [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag). If the switch worked, the page shows your organization's plan and the Claude Tag settings.

## Nothing responds

### Claude is silent everywhere on Enterprise Grid

**What you see**

Mentions get no reaction and no reply in every channel and DM across the Grid, and nothing was changed on the Claude side.

**What it means**

On Enterprise Grid, the Claude app's organization-level authorization can be revoked on Slack's side without anything changing in Claude. When it is, Claude never receives the mentions at all.

**How to resolve**

Reinstall over the existing app. Don't uninstall first; installing over the top is what carries your existing settings over.

1. As a Slack org owner or org admin, sign into one of the Grid's workspaces, not the organization-level admin page. The install option only appears from inside a workspace.
2. Open [Claude for Slack](https://claude.com/claude-for-slack), select **Add to Slack**, and choose **Install to entire organization**.
3. Mention `@Claude` anywhere. If the reinstall worked, the mention gets a reaction and a reply. The pairing survives the reinstall, so a normal reply means you're done. A reply that says the workspace isn't set up means the pairing needs to be redone; see [This workspace isn't set up for Claude Tag yet](#this-workspace-isnt-set-up-for-claude-tag-yet).

See [If `@Claude` doesn't respond at all](/claude-tag/admins/pair-workspace#if-claude-doesnt-respond-at-all).

### This workspace isn't set up for Claude Tag yet

**What you see**

Claude replies to a mention:

> This workspace isn't set up for Claude Tag yet. A workspace admin can run `@Claude connect`, or set it up here.

It ends with a footnote that routes people looking for [the earlier Claude in Slack](/claude-tag/concepts/glossary#the-earlier-claude-in-slack) to that product's own setup guide. The reply varies with the sender: someone who isn't a Slack workspace admin is told to ask their Claude workspace owner to run `@Claude connect`, without the settings link.

**What it means**

The Slack workspace hasn't been paired with a Claude organization.

**How to resolve**

Run [the pairing flow](/claude-tag/admins/pair-workspace). If the fix worked, a mention in the workspace gets a reply.

### Claude isn't available for your organization

**What you see**

Claude replies to a mention:

> Claude isn't available for your organization. Your admin can enable it here.

**What it means**

The **Enable Claude Tag for your organization** toggle is off in admin settings, or your organization isn't enabled for Claude Tag. The toggle that matters is the one in the Claude organization the workspace is actually paired to.

**How to resolve**

1. An Owner switches the toggle on at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag). If the toggle was the problem, a mention in Slack now gets a reply.
2. If the message persists, check which Claude organization the workspace is paired to. If your company has more than one (a trial organization alongside the main one, for example), an Owner in the wrong organization can [revoke the pairing](/claude-tag/admins/workspaces#revoke-a-pairing) so you can pair the workspace to the right one.
3. If the right organization has the toggle on and the message persists, contact your account team to confirm Claude Tag is enabled for it.

### Claude isn't available for organizations with restricted compliance settings

**What you see**

Claude replies to a mention:

> Claude isn't available for organizations with restricted compliance settings.

**What it means**

Claude Tag retains channel memory and session transcripts, so it isn't available to organizations with Zero Data Retention (ZDR) or a similar restricted compliance configuration; see [what Claude Tag retains](/claude-tag/concepts/security-and-data).

**How to resolve**

There's no setting that lifts this; Claude Tag isn't available to these organizations.

### Claude is disabled in this channel

**What you see**

Claude replies in the channel:

> Claude is disabled in this channel. Your admin can re-enable it here.

Only the first sentence is fixed. A sender who isn't a Slack workspace admin is told to ask their Claude workspace owner to re-enable it, without the settings link.

**What it means**

This channel's scope has **Claude Tag version** set to **Off**.

**How to resolve**

An Owner changes the scope's version setting at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag) on the **Slack** tab under **Claude Tag's access**. If the fix worked, a mention in the channel gets a reply.

## Access and connections

Access and connection errors usually mean Claude responded but couldn't reach a connected service, a repository, or a capability the sender's seat doesn't include. A scope left on **Legacy** only looks like an access problem; there, the earlier Claude in Slack answers instead of Claude Tag, so bundles and connections never apply.

### Claude says a host isn't allowed or it can't reach the internet

**What you see**

Claude in a channel says a host isn't allowed, a network request was blocked, or it can't fetch a page, even though the request was ordinary HTTP.

**What it means**

A channel session's outbound network access is deny-by-default. A host is reachable when a bundle's connection or [Domains list](/claude-tag/admins/add-connections#allow-a-host-without-a-credential) allows it, or when the network access setting of the environment the scope's sessions run on allows it; anything else is blocked. Web search is separate and works regardless, so Claude can answer from search while being unable to fetch the same page.

**How to resolve**

* For specific hosts, add them to the bundle's [Domains list](/claude-tag/admins/add-connections#allow-a-host-without-a-credential); a credential-bearing service belongs in a connection instead.
* For broad access, pin an organization-scoped environment with a permissive network access setting on the scope; see [the environment entry below](#channel-sessions-use-the-wrong-environment-or-cant-find-one).

Test in a new thread. If the fix worked, the fetch that failed succeeds there.

### A connection works in one channel but not another

**What you see**

Claude uses a connected service without trouble in one channel, and in another channel says it has no access to the same service.

**What it means**

Bundles attach per scope. The working channel's scope has the bundle; the failing one likely doesn't.

**How to resolve**

Attach the bundle to the failing channel's scope, or move the work to a channel under a covered scope. Test in a new thread, since a session loads its connections when it starts. If the fix worked, asking `@Claude what can you access from this channel?` in the new thread lists the service.

### GitHub doesn't work in this channel

**What you see**

In the channel, Claude says it has no GitHub access, can't find a repository, or opens pull requests under the asker's name instead of its own.

**What it means**

The most likely cause is a channel whose scope still has **Claude Tag version** set to **Legacy**, so the earlier Claude in Slack answers instead of Claude Tag. The other causes are a missing bundle attachment, a stale thread, an ungranted repository, or a repository the GitHub App installation doesn't cover.

**How to resolve**

Go through these checks in order; the same checks, in the same order, apply when GitHub worked in a channel and then stopped.

1. **Which version answers the channel**: if `@Claude` opens pull requests under the asker's name, the channel is on **Legacy**, and bundles only apply where Claude Tag answers. Switch the scope's **Claude Tag version** setting per [Migrate from the earlier Claude in Slack](/claude-tag/admins/restrict-access#migrate-from-the-earlier-claude-in-slack). You're on the right version when pull requests open under the Claude GitHub App.
2. **A bundle with GitHub access on this channel's scope**: bundles attach per scope, so the bundle that carries GitHub access must be attached to a scope that covers this channel; [Attach the bundle to a scope](/claude-tag/admins/attach-to-scope) covers attachment and inheritance. If the bundle is attached, asking `@Claude what can you access from this channel?` in a new thread lists GitHub.
3. **A fresh thread**: a session loads its connections when it starts, so threads already underway don't see ones added later. Start a new thread before checking anything further.
4. **The repository granted in the bundle**: the repository must be listed in the bundle's **Repositories** tab, per [Grant repository access](/claude-tag/admins/configure-github#grant-repository-access). If the repository is granted, asking Claude to read a file from it works in a new thread. Granting makes the repository available to clone, but the code doesn't enter a session until a request names it.
5. **The GitHub App installation covers the repository**: if Claude reports a repository isn't available, isn't configured, or returned a 403, check the installation, since the app's repository selection is upstream of the bundle grant. At [`claude.ai/admin-settings/claude-code/github`](https://claude.ai/admin-settings/claude-code/github), the organization that owns the repository should show **Active** under **Installations**. If it appears under **Unlinked accounts** with a **Needs permissions** status instead, the install is waiting on a GitHub organization owner. Click **Review permissions** to approve it on github.com. If you aren't a GitHub organization owner, use **Copy message** under **Not a GitHub organization owner?** on that settings page to send the request to someone who is. If the organization isn't listed at all, install the app with **Install on another organization**; [Link your GitHub organization](/claude-tag/admins/configure-github#link-your-github-organization) covers both.

For GitHub Enterprise Server repositories, confirm [the GHE host is registered](/claude-tag/admins/configure-github#github-enterprise-server) instead. The github.com App install doesn't cover them.

### I hit an authentication error and couldn't finish this turn

**What you see**

Claude posts in the thread:

> I hit an authentication error and couldn't finish this turn — this session's credentials or integration may need to be reconnected. Once reconnected, mention me to retry.

**What it means**

Claude's own request failed an authentication check partway through the turn, so it stopped, keeping the work done so far. This message doesn't point at a service you connected. When a connected service's credential fails, Claude reports that as a tool error inside its reply, not with this notice. A DM sender whose seat doesn't include Claude Code gets [Your Claude account is connected, but it doesn't have access in this organization](#your-claude-account-is-connected-but-it-doesnt-have-access-in-this-organization) instead.

**How to resolve**

Have the requester mention Claude in the same thread to retry; the session picks up where it stopped. If it recurs on every new thread, contact [Anthropic support](https://support.claude.com) with the channel and the time it happened.

### Your Claude account is connected, but it doesn't have access in this organization

**What you see**

Claude replies in the DM:

> Your Claude account is connected, but it doesn't have access in this organization — usually this means your admin hasn't assigned you a seat that includes Claude Code. Ask them to add one, then mention me to retry.

**What it means**

DMs run on the user's own claude.ai account and need a seat that includes Claude Code; this user's seat doesn't include it. Mentioning `@Claude` in a channel doesn't depend on the sender's seat.

**How to resolve**

Assign the user a seat that includes Claude Code on the **Members** page at [`claude.ai/admin-settings/members`](https://claude.ai/admin-settings/members), then have them mention Claude in the same DM thread. If the fix worked, the DM gets a reply instead of this message.

## Session start errors

Session start errors appear before any work begins. Some are transient and clear on retry; the rest point to capacity or environment configuration rather than credentials.

### Still waiting for available capacity

**What you see**

Claude posts in the thread:

> Still waiting for available capacity — your request is queued and will start automatically. Replies in this thread are picked up automatically.

**What it means**

Compute capacity is temporarily busy. The session starts on its own once capacity frees up.

**How to resolve**

Wait; no action is needed. Users should reply in the same thread if they have more to add, since starting a new thread only queues a second session behind the first.

### Session failed to start: the session container never connected

**What you see**

Claude posts in the thread:

> Session failed to start: the session container never connected — please try again

**What it means**

The session's compute container didn't come up in time. This is transient.

**How to resolve**

Mention Claude in the same thread to retry. If the retry worked, the session starts and Claude begins the task.

### Something went wrong starting a session

**What you see**

Claude posts in the thread:

> Something went wrong starting a session. Try again in a moment.

When Claude can name the cause, it posts one of these instead:

| Message                                                                                              | Cause                                                                                                                                                       |
| ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| "Hit the session rate limit — try again in a few seconds." (or "in \~Ns" when Claude knows the wait) | Too many sessions started at once; wait, then mention Claude again                                                                                          |
| A message naming a specific repository that isn't available or isn't configured                      | The repository isn't granted for this channel; see [GitHub doesn't work in this channel](#github-doesnt-work-in-this-channel)                               |
| "That environment or repo isn't configured for Claude Code. Check claude.ai/code and try again."     | The scope's pinned environment isn't set up; see [Channel sessions use the wrong environment](#channel-sessions-use-the-wrong-environment-or-cant-find-one) |
| "Claude Code Remote is temporarily degraded. Try again shortly."                                     | The service that runs sessions is briefly unavailable; retry                                                                                                |
| "You don't have permission to start a session here."                                                 | A permission check refused to start the session; when Claude knows which check failed, the message names it                                                 |

**What it means**

This is the catch-all for session-start failures that don't map to a more specific message, so the cause varies. It's usually transient.

**How to resolve**

Mention Claude again in the same thread before changing any configuration; the retry usually clears it. If a specific message from the table above appears instead, follow its row.

### Channel sessions use the wrong environment, or can't find one

**What you see**

Sessions in a channel start on an environment you didn't expect, or session starts fail with the environment message from the table above.

**What it means**

Each scope at [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), on the **Slack** tab under **Claude Tag's access**, has an **Environment** picker (in the scope's **Advanced** section) that pins the Claude Code environment or runner pool that sessions in that scope use. With nothing pinned, sessions use the **Organization default**. The picker only lists environments scoped to the organization; an environment created under an individual account doesn't appear, because channel sessions run with no user account attached.

**How to resolve**

If the environment you want isn't in the dropdown, recreate it as an organization-scoped environment at [`claude.ai/code`](https://claude.ai/code), then pin it on the scope. If the fix worked, a new thread's session runs on the pinned environment. See the [glossary entry on environments](/claude-tag/concepts/glossary#environment).

## Related resources

* [Setup overview](/claude-tag/admins/setup-overview): re-walk the setup steps if the failure points to one you skipped
* [User troubleshooting](/claude-tag/users/troubleshooting): for problems people hit in channels
* [Give feedback](https://support.claude.com): when it's a bug, not a configuration issue
