[BUG] [Cowork] settings.json deny rules for WebFetch and WebSearch not enforced in Cowork desktop app

Resolved 💬 3 comments Opened Apr 27, 2026 by arapehl Closed May 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?

The deny permission rules in settings.json for WebFetch and WebSearch tools have no effect in the Cowork desktop app. Claude successfully searches the web and fetches URLs even when explicit deny rules are present in both the global ~/.claude/settings.json and project-level .claude/settings.json. Restarting the app does not help.

Notably, Bash deny rules (e.g. Bash(curl *), Bash(wget *)) do work correctly — the problem is specific to the built-in WebFetch and WebSearch tools.

What Should Happen?

Claude should be unable to use WebFetch or WebSearch when those tools are listed in the deny array, consistent with how Bash deny rules are enforced.

Error Messages/Logs

None — no error is shown. Claude proceeds to use the tools as if no deny rules exist.

Steps to Reproduce

  1. Add deny rules to ~/.claude/settings.json:

{
"permissions": {
"deny": ["WebFetch", "WebSearch"]
}
}

  1. Restart the Cowork desktop app
  2. Open any project
  3. Ask Claude to search the web (e.g. "Can you search the web for X?")
  4. Observe: Claude successfully searches the web despite the deny rules

Also tested: project-level .claude/settings.json with the same deny rules — also has no effect.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.4758.0 (fb266c) 2026-04-24T20:22:30.000Z

Platform

Other

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Use case: users managing sensitive personal data (financial records, health documents) in Cowork want to hard-restrict web access in specific projects to mitigate prompt injection risks, while keeping web access enabled in other projects (e.g. a daily news briefing project). Without working deny rules, no technical enforcement layer is available — only CLAUDE.md soft controls, which a crafted injection attack could theoretically override.

Workaround in place: CLAUDE.md directives prohibiting web access + Bash(curl *) / Bash(wget *) deny rules (which do work). But WebFetch and WebSearch remain technically unblocked.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗