deny and ask rules in settings.json have no effect on Write/Edit/Read tools

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?

deny and ask permission rules in ~/.claude/settings.json have no effect on the Write, Edit, and Read tools. File write operations are neither blocked nor prompted regardless of what deny/ask rules are configured. Only Bash(...) rules are respected by the permission system.

What Should Happen?

deny rules should block file tool operations (Write, Edit, Read) at the specified paths, and ask rules should always trigger a confirmation dialog before the operation proceeds — regardless of whether the request came from the user explicitly or from Claude autonomously.

Error Messages/Logs

None. That is part of the problem — denied and ask-gated operations complete silently with no error, no log entry, and no dialog. There is no indication that the permission rules were evaluated at all.

Steps to Reproduce

1. Add the following to ~/.claude/settings.json:

```json
{
"permissions": {
"defaultMode": "default",
"deny": ["Write(/home/<user>/*)"],
"allow": ["Write(/home/<user>/.claude/projects/*)"]
}
}

1. Restart VS Code to ensure settings are loaded
2. Ask Claude to write a file outside the allow list, e.g. Write(/home/<user>/spaces/<project>/test.md)
3. Observe: file is created without any prompt or error

Repeat with "ask": ["Write(/home/<user>/spaces/<project>/*)"] in place of deny — no confirmation dialog appears.
Tested with both "defaultMode": "plan" and "defaultMode": "default" — behavior identical in both modes.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.218

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Related to issue #80868 (ask rules failing to gate compound Bash commands) — both point to the same underlying problem: permission rules are not consistently evaluated across tool types and command structures.

Additional findings from the same test session:

• additionalDirectories: ["/home/<user>/spaces"] grants implicit Bash and Read access to the entire directory tree, not just the listed path. Subdirectories not mentioned anywhere in the allow list were accessible without any prompt.
• A syntactically invalid settings.json (e.g. trailing comma) silently falls through rather than failing closed (deny all).

After filing this report, the following related issues were suggested:

• #75315: Path-scoped Write(...) allow rules never match — only Edit(...) rules gate the Write tool. This likely explains our finding: deny: ["Write(/home/john/*)"] was always wrong syntax; deny: ["Edit(/home/john/*)"] may be the correct form. Not yet tested.
• #74567: --permission-mode dontAsk denies Write/Edit regardless of --allowedTools/permissions.allow
• #54087: deny rules for WebFetch/WebSearch not enforced (closed)

Tested deny: ["Edit(/home/john/*)"] as a workaround based on #75315 — no effect.
File writes still complete silently. deny rules appear non-functional for file tools
regardless of whether Write(...) or Edit(...) syntax is used.

Note: during testing, the env var CLAUDE_CODE_CHILD_SESSION=1 was set, indicating
Claude ran as a child session within the VS Code extension. It is possible that
deny rules from ~/.claude/settings.json are not enforced in child sessions.