Hooks don't receive tool input for Read/Glob; permission patterns don't match tilde paths
Summary
PreToolUse hooks for Read/Glob tools do not receive tool input parameters as environment variables, making it impossible to validate or intercept file paths before execution. Additionally, permission patterns containing tilde (~) do not match agent-generated tilde paths.
Environment
- Claude Code v2.1.5
- Windows 11 (Git Bash / MINGW64)
- Model: Opus 4.5
Problem 1: Hooks don't receive tool input for Read/Glob
Expected Behavior
PreToolUse hooks should receive tool input parameters as environment variables, similar to how Bash hooks receive CLAUDE_TOOL_INPUT_COMMAND.
For Read: CLAUDE_TOOL_INPUT_FILE_PATH
For Glob: CLAUDE_TOOL_INPUT_PATH and CLAUDE_TOOL_INPUT_PATTERN
Actual Behavior
Hooks only receive:
CLAUDE_PROJECT_DIRCLAUDE_CODE_ENTRYPOINT
No tool-specific input variables are provided. This was verified by dumping all environment variables from within the hook.
Impact
Cannot create hooks to validate/fix file paths before tool execution. This is critical for Windows environments where path format issues cause permission prompts.
Problem 2: Permission patterns don't match tilde paths
Setup
User-level ~/.claude/settings.local.json contains:
{
"permissions": {
"allow": [
"Read(~\Projects\**)",
"Read(~/Projects/**)",
"Glob(~\Projects\**)"
]
}
}
Expected Behavior
These patterns should match paths like ~\Projects\Aletheia-310\src\file.py
Actual Behavior
Permission prompt appears:
Read(~\Projects\Aletheia-310\src\lambda_function.py)
Do you want to proceed?
The pattern Read(~\Projects\**) does not match ~\Projects\Aletheia-310\...
Problem 3: Model generates tilde paths despite explicit instructions
Even with explicit prompt instructions like:
PATH FORMATS (MANDATORY):
- Read/Write/Edit/Glob: C:\Users\mcwiz\Projects\Aletheia\path\to\file
- NEVER use ~ or ~\ - these are FORBIDDEN
And CLAUDE.md containing:
THE TILDE CHARACTER (~) DOES NOT EXIST. NEVER USE IT.
Opus still generates:
Read(~\Projects\Aletheia-310\src\etymologist.py)
Note: The Claude Code banner itself displays ~\Projects\Aletheia which may be where the model picks up this format.
Reproduction Steps
- On Windows, create a worktree in a subdirectory
- Configure a PreToolUse hook for Read that logs all environment variables
- Have the model attempt to Read a file in the worktree
- Observe: hook receives no file path information
- Observe: permission prompt appears despite matching patterns in settings
Requested Fixes
- Expose tool input to hooks - Provide
CLAUDE_TOOL_INPUT_*environment variables for all tools, not just Bash - Fix tilde pattern matching - Ensure
Read(~\Projects\**)matches~\Projects\...paths - Consider normalizing paths - Before permission check, normalize tilde paths to absolute paths
Workaround Attempted
Added Read(**) and Glob(**) to allow any path - testing pending.
13 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Additional Finding: Pattern matching is completely broken
After further testing, even the most permissive patterns don't work:
Read(**)- Does NOT match any Read callsGlob(**)- Does NOT match any Glob callsSearch(**)- Does NOT match any Search callsBash(gemini:*)- Does NOT matchgemini -p "..."commandsUser is still prompted for approval on EVERY Read/Search/Glob operation and even Bash commands that should match existing patterns.
The permission pattern matching system appears to be completely non-functional. No patterns are matching, regardless of specificity or wildcards.
This is blocking automated agent workflows entirely.
Additional Bug:
|Inside Quoted Strings Triggers ApprovalRelated to the pattern matching issues above, I've discovered another problem:
Command that triggers approval prompt:
Why this should NOT trigger approval:
|character is inside a double-quoted stringgeminicommandExpected behavior: Commands with
|inside quoted strings should not be flagged as containing shell operators.Actual behavior: The entire command is flagged for approval.
Root cause hypothesis: The permission system does a naive string scan for
|anywhere in the command, without parsing to understand shell quoting context.This affects any command that passes text containing
|as an argument, which is common when invoking AI tools that receive natural language prompts.Re: Potential Duplicates
I've reviewed the linked issues:
What's UNIQUE in this issue that's NOT covered elsewhere:
Pattern Matching is Completely Non-Functional
The most severe finding is that no permission patterns match anything, regardless of format:
User is STILL prompted for approval on EVERY operation. The entire permission system appears non-functional on Windows.
This is distinct from the tilde-specific path issues in #16800. Even with the most permissive wildcards possible, nothing auto-approves.
The
|Inside Quotes IssueAdditionally, Bash commands containing
|inside quoted strings (not as shell operators) trigger approval prompts. This is likely due to naive string scanning rather than proper shell parsing.---
I'll close the duplicate aspects (hooks stdin - same as #17424), but please keep this open for:
|inside quotes triggering approval👎 (preventing auto-closure)
Edit Tool Also Affected
Pattern matching is also broken for the Edit tool:
Configured permission:
Prompts still appearing:
These files are at:
C:\Users\mcwiz\Projects\Aletheia-310\src\etymologist.pyC:\Users\mcwiz\Projects\Aletheia-310\extensions\chrome\overlay.jsBoth clearly match
C:\Users\mcwiz\Projects\**but prompts appear anyway.Summary of broken tools:
Read(**)- doesn't matchGlob(**)- doesn't matchSearch(**)- doesn't matchEdit(C:\Users\mcwiz\Projects\**)- doesn't matchBash(gemini:*)- doesn't matchThe entire permission system appears non-functional on Windows.
Write Tool Also Affected
Pattern matching is broken for the Write tool as well:
Configured permission:
Prompts appearing:
Files are at paths like:
C:\Users\mcwiz\Projects\Aletheia-310\tests\unit\test_poetic_analyzer.pyC:\Users\mcwiz\Projects\Aletheia-106\extensions\chrome\article-extractor.jsC:\Users\mcwiz\Projects\Aletheia\docs\context.htmlAll paths clearly match
C:\Users\mcwiz\Projects\**.Also:
Bash(mkdir:*)not matchingmkdir -p /c/Users/mcwiz/Projects/Aletheia-310/docs/reports/310---
Complete list of broken tools:
Read(**)- doesn't matchWrite(C:\Users\mcwiz\Projects\**)- doesn't matchEdit(C:\Users\mcwiz\Projects\**)- doesn't matchGlob(**)- doesn't matchSearch(**)- doesn't matchBash(mkdir:*)- doesn't matchBash(gemini:*)- doesn't matchEvery tool type's permission matching is broken on Windows.
More Friction Events (Batch 3)
Continuing to document every permission prompt:
Edit prompt:
Path:
C:\Users\mcwiz\Projects\Aletheia-106\src\lambda_function.pyPattern exists:
Edit(C:\Users\mcwiz\Projects\**)Bash cp prompt:
Pattern exists:
Bash(cp:*)---
These are now 6 separate sessions all experiencing the same issue. Permission patterns exist but nothing matches.
User has had to manually approve ~50+ prompts in the last 2 hours alone.
More Friction Events (Batch 4)
git commit prompt:
Pattern exists:
Bash(git:*)Write prompts (2x):
Pattern exists:
Write(C:\Users\mcwiz\Projects\**)mkdir prompt:
Pattern exists:
Bash(mkdir:*)pip-audit prompt:
(No pattern - but wouldn't matter since nothing matches anyway)
---
Total manual approvals today: ~75+ across 8 sessions.
Every tool type remains broken on Windows.
Friction Batch 5 (End of Night)
curl prompt:
Pattern needed:
Bash(curl:*)(exists in allowlist)Write prompts (3x):
Pattern exists:
Write(C:\Users\mcwiz\Projects\**)---
Total manual approvals tonight: ~80+ across 10+ sessions.
Every single permission pattern is non-functional on Windows. The permission system provides zero value - it's pure friction with no security benefit since we approve everything anyway.
Friction Batch 6 (12 more events in 15 minutes)
User is trying to go to sleep. Agents keep triggering prompts.
Bash prompts:
Patterns exist:
Bash(git:*),Bash(chmod:*)Write/Edit prompts (7x):
Pattern exists:
Write(C:\Users\mcwiz\Projects\**)---
Running total tonight: ~95 manual approvals
This is across 12+ agent sessions. User cannot leave agents running unattended because EVERY operation requires manual approval.
The permission system is not just broken - it's actively hostile to productivity.
I'm experiencing this on linux.
I have some markdown guidelines for claude stored in
~/.claude/guidelines/I've given global permission to read these:
But it never matches and I'm constantly asked for read permission.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.