[BUG] Cowork: sandboxed Bash blocks outbound POST/write requests to an explicitly allowlisted domain (works for GET, fails for POST) — regression since ~Aug 11–26, 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?

In a Cowork cloud session, the sandboxed Bash tool blocks any outbound POST request to a domain that is explicitly present in the organization's "Additional allowed domains" list (Settings → Capabilities → Domain allowlist), even though GET requests to the same domain, in the same session, succeed immediately.

This breaks a previously-working, PIN-gated publish workflow (curl POST to a Cloudflare Worker endpoint we control, which writes a file to our own GitHub Pages repo). The workflow ran successfully across roughly 70 prior sessions. It stopped working between our last known-good session (closed 2026-08-11) and our next attempt (2026-08-27).

Concretely, in one session:

curl GET https://<our-worker-domain>/flags (no auth) → blocked by "Claude Code auto mode classifier"
Domain added to org's Capabilities → Domain allowlist → "Additional allowed domains"
Same curl GET .../flags retried → succeeds, HTTP 200, real JSON returned
curl POST .../deploy with a JSON body containing {"pin": "...", "path": "...", "content": "...", "message": "..."} (our own documented, previously-working publish call) → blocked by the same classifier
To isolate the cause, retried the POST with no credential-like field at all (no pin, just path/content/message) → still blocked, identically

So the discriminator is not the domain (already allowlisted, and GET works), and it is not the presence of a pin-shaped field (removing it changed nothing) — it appears to be the HTTP method / write-action itself to a domain that is otherwise fully reachable.

Separately, a plain git ls-remote to github.com (not on the allowlist) and a curl to api.github.com (added to the allowlist) were also blocked or routed through an unrelated GitHub-integration gate ("Use add_repo to request access") rather than the domain-allowlist mechanism — suggesting there may be more than one overlapping permission layer here, and their interaction isn't obvious to the end user from the Capabilities UI.

What Should Happen?

At minimum, one of:

The Domain allowlist UI should document that it only affects read (GET) traffic, if that is intentional — the current copy ("Choose which domains the sandbox can access") implies full access, not read-only access.
OR, if blocking POST/PUT/DELETE to allowlisted domains is intentional hardening, there should be a way for an org owner to explicitly grant write access to a specific, vetted domain (separate from and stricter than the read allowlist), so a documented, low-risk, PIN-gated automation the org built and controls can keep functioning without a human manually executing every call.
Either way, the denial message should distinguish "this host isn't reachable" from "this host is reachable but write methods are blocked here" — right now both look identical, which makes the allowlist feature actively misleading (it appears to fix the problem, via a working GET, while the actual blocker for our use case is untouched).

Error Messages/Logs

Permission for this action was denied by the Claude Code auto mode classifier. Reason: Blocked by classifier.
If you have other tasks that don't depend on this action, continue working on those.
IMPORTANT: You *may* attempt to accomplish this action using other tools that might naturally be
used to accomplish this goal... but you *should not* attempt to work around this denial in malicious
ways... You should only try to work around this restriction in reasonable ways that do not attempt to
bypass the intent behind this denial. If you believe this capability is essential to complete the
user's request, STOP and explain to the user what you were trying to do and why you need this
permission. Let the user decide how to proceed.

Steps to Reproduce

In a Cowork cloud session, run curl -s "https://<any-domain-not-yet-allowlisted>/<endpoint>" → observe classifier denial.
As the org owner, add that domain to Settings → Capabilities → Domain allowlist → "Additional allowed domains."
In the same (or a new) Cowork session, retry the identical GET → succeeds.
In the same session, run curl -s -X POST "https://<same-domain>/<endpoint>" -H "Content-Type: application/json" -d '{"path":"test","content":"test","message":"test"}' (no secrets in the body) → observe the same classifier denial as step 1, despite the domain being allowlisted and GET already proven to work.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Not directly known — Cowork does not expose a claude --version-equivalent to the end user. Bounding evidence: our workflow worked through a session closed 2026-08-11, and first failed in a session on or shortly before 2026-08-27. The public Claude Code changelog shows several changes to sandbox network/credential handling in that exact window that look relevant and may or may not share code with Cowork's sandbox: v2.1.238 (2026-08-20, sandbox credential-file masking on egress), v2.1.243 (2026-08-25, auto-mode availability fixes), and v2.1.247 (2026-08-26, changed how the sandboxed Bash tool surfaces allowed network hosts — no longer listed upfront, now discovered per-attempt).

Claude Code Version

N/A — this is Cowork (cloud, desktop app), not the local Claude Code CLI, so claude --version doesn't apply. Flagging in case Cowork's cloud sandbox shares the versioned component described in the CLI changelog above.

Platform

Other

Operating System

Other

Terminal/Shell

Other

Additional Information

Related open issues describing the same broader pattern (auto-mode classifier blocking previously-authorized actions, including explicit in-conversation user authorization): #58222, #64576. Neither includes GET-vs-POST or allowlist-vs-classifier evidence as specific as this report.
Our automation is a PIN-gated (not secret-token) endpoint we built and fully control (a Cloudflare Worker with a hardcoded 4-digit operator PIN, documented in our own project's internal runbook), used solely to publish our own static site to our own GitHub Pages repo. We are not asking to bypass any restriction on secrets or third-party systems — only to restore write access to a domain we, the org owner, have explicitly vetted and allowlisted ourselves.
Happy to provide the exact (harmless, already-public) domain names and a full session transcript on request.