[BUG] Claude Tag "All apps" access bundles override Cowork network egress, and bundle scope/method defaults are unclear

Status Open
Reported on v2.1.285
Maintainer reply None cached
Activity 0 comments · opened Sep 30, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Summary

As an org owner I wanted Claude Tag (Slack) to have one internal connector without giving it to every member's personal Claude account. Doing that exposed several confusing behaviors in the admin settings. The worst one: a Claude Tag access bundle attached under "All apps" replaced the Capabilities network allowlist for Cowork sessions, so Cowork broke for everyone, and neither settings page nor the block error pointed to the bundle.

Environment

  • Plan: Team
  • Surfaces: Claude Tag in Slack, Cowork
  • Date observed: 2026-09-30

Issues

1. A bundle under Claude Tag › "All apps" overrides Capabilities › Code execution for Cowork

Settings › Capabilities › "Allow network egress" is tagged Chat and Cowork, and our Domain allowlist is "All domains" ("Claude can access all domains on the internet"). The page now also notes that egress controls don't apply to web search, web fetch or MCP connectors.

With a bundle attached under Claude Tag › "All apps", Cowork sandbox sessions followed the bundle's network rules instead. The "All apps" page says it applies to "all connected apps and Claude Code cloud sessions". It doesn't mention Cowork.

The docs say "Cowork respects your organization's network egress permissions set in Organization settings › Capabilities". In practice it didn't.

<img width="1047" height="251" alt="Image" src="https://github.com/user-attachments/assets/c9210320-dd68-4aad-90e6-bd21a959c3cf" />

2. Creating a bundle for a Slack workspace also attached it under "All apps"

I set up a bundle for our Slack workspace, and it also appeared under "All apps" (org-wide) without my choosing that. To keep it Slack-only I had to remove it from "All apps" by hand, then re-test Cowork for individual users.

3. Domain entries default to read-only methods, and the block error doesn't say which setting is responsible

New domain entries in a bundle default to Read-only (GET, HEAD, OPTIONS), shown only under a collapsed "Advanced" section. Our MCP server's domain was in the bundle that way, so a POST upload from the Cowork sandbox to that server was blocked (output below). The error names the method but not where the rule lives. Capabilities said "All domains", so nothing pointed to the Claude Tag bundle.

<img width="732" height="356" alt="Image" src="https://github.com/user-attachments/assets/2d52108d-3fbf-461f-8222-72473b2c1d09" />

4. "Used in 0 places" doesn't say what it means

The bundles list shows "Used in 0 places" for unattached bundles. It isn't clear whether an unattached bundle grants anything.

<img width="1003" height="232" alt="Image" src="https://github.com/user-attachments/assets/b4acb484-a290-40fd-9b18-f8a2d10937a0" />

What Should Happen?

  • Each settings page shows which surfaces it actually governs, and says when another setting overrides it (for example, a Claude Tag bundle overriding Capabilities for Cowork).
  • A bundle is never attached org-wide unless the admin picks that scope.
  • Allowed methods are visible on each domain entry without expanding it.
  • Block messages name the setting the rule comes from (e.g. "blocked by Claude Tag access bundle <name>").
  • Connectors meant for Claude Tag stay separate from members' personal access.
  • "Used in N places" says whether the bundle is active.

Error Messages/Logs

# While the bundle was attached under "All apps" (host, domain, token and path redacted):
$ curl -sS -X POST --data-binary @Cowork_Attachment_Test.xlsx "https://<our-mcp-host>/uploads/<upload-token>" -w "\nHTTP %{http_code}\n"
request blocked: no rule allows host "<our-mcp-host>" - "*.<our-domain>" allows the host but not method POST (allowed: "GET", "HEAD", "OPTIONS")
HTTP 403

# After removing the bundle from "All apps":
$ curl -sS -X POST --data-binary @test_attachment.xlsx -H "Content-Type: application/octet-stream" -w "\nHTTP %{http_code}\n" "https://<our-mcp-host>/uploads/<upload-token>"
{"ok":true,"bytes":5060,"path":"<redacted>"}
HTTP 200

Steps to Reproduce

  1. Capabilities › Code execution: turn on network egress and set Domain allowlist to "All domains" (same w/package managers only + specific allowlisted domains)
  2. Claude Tag › create an access bundle with a credential and one domain (e.g. *.example.com), keeping the default methods, and attach it to a Slack workspace.
  3. Check Claude Tag › "All apps": the bundle is attached there too.
  4. In a Cowork session, POST from the sandbox to a host under that domain (e.g. curl -X POST), or reach a host outside the bundle. It fails with request blocked: ... even though Capabilities says "All domains".
  5. Remove the bundle from "All apps" and keep it on the Slack workspace only. The same POST returns 200.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.285 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Possibly related

#93512 and #93677 (Cowork ignores "All domains") might have the same cause on orgs using Claude Tag. Before/after output and diagnostic notes in my comment there: https://github.com/anthropics/claude-code/issues/93512#issuecomment-5917587254
#44980 (closed) asked for per-member scoping of org connectors.

View original on GitHub ↗