Bug Report: Path Patterns in allowedTools Not Honored in Non-Interactive Mode
Environment
Other: Claude Code CLI tool
Claude CLI version: v0.2.122
Operating System: Windows 11 with WSL2 (Ubuntu)
Terminal: Bash in WSL
Bug Description
Claude Code ignores path patterns in allowedTools configuration when running in non-interactive mode (with -p flag). While simple tool permissions (e.g., "Write") work correctly, any path-specific permissions (e.g., "Write(/path/**)") are completely ignored in non-interactive mode, despite being correctly configured and visible in claude config list.
Steps to Reproduce
Configure path-specific tool permissions:
bashclaude config add allowedTools "Write(/mnt/c/path/to/project/**)"
claude config list # Confirms the permission is saved
Run Claude Code in non-interactive mode targeting a path matching the pattern:
bashclaude -p "write a test file to /mnt/c/path/to/project/test.md" --output-format stream-json
Observe that Claude requests permissions despite matching the allowed path pattern.
Test with universal wildcard to confirm it's not a path matching issue:
bashclaude config add allowedTools "Write(/**)" # Most permissive pattern possible
claude -p "write a test file to /any/path/test.md" # Still asks for permission
Expected Behavior
Claude Code should honor the path patterns configured in allowedTools settings when running in non-interactive mode, just as it does in interactive mode.
Actual Behavior
Claude Code always requests permission for path-based tools when running in non-interactive mode, regardless of path patterns specified in allowedTools. However, when configured with simple tool names without paths (e.g., "Write" instead of "Write(/path/**)") it works correctly.
Additional Context
When run with --allowedTools Bash, Claude Code correctly identifies its working directory and execution context, confirming there are no path resolution issues at the operating system level:
bashclaude -p "Führe den Befehl 'pwd' aus und zeige mir dein aktuelles Arbeitsverzeichnis." --allowedTools Bash
Returns correct working directory and permissions
This issue prevents using path-restricted permissions in CI/CD pipelines, scripts, or any other non-interactive workflows, significantly limiting Claude Code's security model in automated contexts.
The only workaround is to use simple tool permissions without path patterns:
bashclaude config add allowedTools Write # No path pattern
Or specify permissions directly via command line:
bashclaude -p "your prompt" --allowedTools Write
This appears to be related to Issue #581 ("Bug: Claude CLI non-interactive mode doesn't respect configured tool permissions") but specifically concerns path pattern matching.
8 Comments
MCP settings are also not respected. It picks up the global settings, but does not allow passing in mcpSettings.
It would be great to have some indication of whether this is even being looked at
Spent much more time than I should have on this issue today... I find it extremely limiting to not be able to restrict the Edit tool to some file pattern in non-interactive setting. For the use case I have right now it's even a deal breaker see #6194.
I am not sure I could do it through hooks because the whole point of what I want to do is to restrict Claude dynamically while using the python SDK (to let it edit only one file at a time).
At the very least this should be documented somewhere that it doesn't work.
FYI look like someone from anthropic got assigned on the issue I opened on the same topic #6194 so we might have update on that there.
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
This is definitely still an issue as far as I know!
This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.
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.