[BUG] [Cowork] settings.json deny rules for WebFetch and WebSearch not enforced in Cowork desktop app
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
- Add deny rules to
~/.claude/settings.json:
{
"permissions": {
"deny": ["WebFetch", "WebSearch"]
}
}
- Restart the Cowork desktop app
- Open any project
- Ask Claude to search the web (e.g. "Can you search the web for X?")
- 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.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗