Wildcard Permission Matching Failure for Curl Commands in Claude Code

[fwends]

Bug Description Subject: Claude Code Permission System Not Working - Curl Commands Still Being Blocked Despite Comprehensive Wildcards

Bug Description: The Claude Code permission system in .claude/settings.local.json is not properly recognizing wildcard patterns for curl commands. Despite having extensive wildcard permissions including "", "Bash()", "curl *", "curl", and "Bash(curl)", curl commands are still intermittently blocked and require user approval.

Expected Behavior: All curl commands should execute without stopping when comprehensive wildcard permissions are configured in the settings file.

Actual Behavior: Curl commands randomly stop execution and ask for permission despite being explicitly whitelisted with multiple wildcard patterns.

Configuration Details:

• File: /Users/greg/codebase/.claude/settings.local.json
• Platform: macOS (Darwin 24.5.0)
• Claude Code Model: claude-sonnet-4-20250514

Permissions Configured: { "permissions": { "allow": [ "", "Bash()", "curl()", "curl ", "curl", "Bash(curl)", "Bash(curl)", "Bash(curl:)", "Bash(curl -*)", "Bash(curl * *)", "Bash(curl * * *)", // ... plus 100+ specific curl patterns ], "deny": [] } }

Specific Examples That Still Get Blocked:

• curl -X PUT "http://localhost:3351/api/..." -H "Content-Type: application/json" -d '{"key":"value"}'
• curl -s "http://localhost:3351/api/tasks" | jq
• Various curl commands with different flag combinations

Impact: This breaks automated workflows and forces manual intervention for every curl command, making Claude Code unusable for API-heavy development tasks.

Reproduction Steps:

1. Configure comprehensive curl wildcards in .claude/settings.local.json
2. Attempt to run various curl commands through Claude Code
3. Observe that some commands still trigger permission requests

Request: Please fix the permission pattern matching system to properly respect wildcard patterns, especially the global "" and "Bash()" patterns which should theoretically allow any command.

Environment Info

• Platform: darwin
• Terminal: vscode
• Version: 1.0.35
• Feedback ID: 8bd43805-6977-48a4-bd3a-01766423c25a

Errors

[{"error":"Error: Command failed: security find-generic-password -a $USER -w -s \"Claude Code\"\nsecurity: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.\n\n    at genericNodeError (node:internal/errors:983:15)\n    at wrappedFn (node:internal/errors:537:14)\n    at checkExecSyncError (node:child_process:892:11)\n    at execSync (node:child_process:964:15)\n    at TZ (file:///opt/homebrew/lib/node_modules/@anthropic-ai/claude-code/cli.js:700:3921)\n    at file:///opt/homebrew/lib/node_modules/@anthropic-ai/claude-code/cli.js:622:9014\n    at Q (file:///opt/homebrew/lib/node_modules/@anthropic-ai/claude-code/cli.js:526:17199)\n    at VX (file:///opt/homebrew/lib/node_modules/@anthropic-ai/claude-code/cli.js:622:8160)\n    at nS (file:///opt/homebrew/lib/node_modules/@anthropic-ai/claude-code/cli.js:622:7241)\n    at f9 (file:///opt/homebrew/lib/node_modules/@anthropic-ai/claude-code/cli.js:622:11408)","timestamp":"2025-06-29T08:18:41.487Z"}]

[BruceTrevarthen]

Yes, please, urgently, this slows down progress immensely - espcially in testing.

[nsheff]

Related, I added this to "allow": in settings:

      "Edit(*plan.md)",

But claude doesn't recognize it; still prompts whenever needing to write to the file.

[github-actions[bot]]

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/3428
2. https://github.com/anthropics/claude-code/issues/4787
3. https://github.com/anthropics/claude-code/issues/1569

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[fwends]

sigh

[tonydehnke]

Running into the same issues too. Across multiple commands - on MacOS.

[nbrustein]

This comment claims that claude does not support wildcards. But claude code seems to allow rules with wildcards itself when you select the option to allow things in the future. For example, claude code wrote this in my settings: "Bash(git commit:*)",

Is that comment just wrong?

[sbs44]

Permissions Configured: { "permissions": { "allow": [ "", "Bash()", "curl()", "curl ", "curl", "Bash(curl)", "Bash(curl)", "Bash(curl:)", "Bash(curl -*)", "Bash(curl * *)", "Bash(curl * * *)", // ... plus 100+ specific curl patterns ], "deny": [] } }

@fwends – have you tried "Bash(curl:*)" (asterisk/wildcard after the colon)? That seems to work for me and follows the pattern that Claude Code uses in the settings.local.json if you select the "Yes, and don't ask again..." option for a given command prefix.

https://github.com/anthropics/claude-code/issues/3428#issuecomment-3067250906 claims that claude does not support wildcards. But claude code seems to allow rules with wildcards itself when you select the option to allow things in the future. For example, claude code wrote this in my settings: "Bash(git commit:*)",

Is that comment just wrong?

@nbrustein – it definitely supports wildcards... I think he just worded his comment poorly. He's basically saying that to allow all Bash commands (which for the record, I have no clue why you would want to do that), you would use "Bash" instead of "Bash:*". But for a specific command (e.g., if you want to allow all lsof commands), you can use wildcards to do that ("Bash(lsof:*)").

[monkeyden]

Permissions Configured: { "permissions": { "allow": [ "", "Bash()", "curl()", "curl ", "curl", "Bash(curl)", "Bash(curl)", "Bash(curl:)", "Bash(curl -*)", "Bash(curl * *)", "Bash(curl * * *)", // ... plus 100+ specific curl patterns ], "deny": [] } }

@fwends – have you tried "Bash(curl:*)" (asterisk/wildcard after the colon)? That seems to work for me and follows the pattern that Claude Code uses in the settings.local.json if you select the "Yes, and don't ask again..." option for a given command prefix.

#3428 (comment) claims that claude does not support wildcards. But claude code seems to allow rules with wildcards itself when you select the option to allow things in the future. For example, claude code wrote this in my settings: "Bash(git commit:*)", Is that comment just wrong?

@nbrustein – it definitely supports wildcards... I think he just worded his comment poorly. He's basically saying that to allow all Bash commands (which for the record, I have no clue why you would want to do that), you would use "Bash" instead of "Bash:*". But for a specific command (e.g., if you want to allow all lsof commands), you can use wildcards to do that ("Bash(lsof:*)").

That's the same syntax I have for jq: "Bash(jq:*)"

That particular one doesn't work but others seem to work perfectly fine: "Bash(mv:)" "Bash(mkdir:)"

[fwends]

@monkeyden @nbrustein @sbs44

you know the issue is from 4 months ago right, now i just use bypass it's easier than messing about with claude options i don't know if it got fixed, but it was not working no matter what i did and yes everything was tried to make it work, it was a claude issue not a problem between keyboard and chair!

[nsheff]

I don’t have a concrete reproducible example yet, but I ran into a problem where if there’s even a slight syntax or command issue in the settings file, Claude silently ignores the entire file. This makes it look like it’s ignoring your allow permissions.

Through trial and error, I found that certain allow permission lines would cause Claude to fail to parse the file. If I removed just that line, the rest of the permissions worked as expected. The commands looked valid at first glance but still triggered the issue.

To debug, I used the /permissions command to check what had been granted. By progressively tweaking the file and removing lines, I was able to isolate the problematic entry.

Summary: a single invalid allow line causes Claude to silently discard all permissions from the settings file, with no error message or warning.

[monkeyden]

@monkeyden @nbrustein @sbs44

you know the issue is from 4 months ago right, now i just use bypass it's easier than messing about with claude options i don't know if it got fixed, but it was not working no matter what i did and yes everything was tried to make it work, it was a claude issue not a problem between keyboard and chair!

I couldn't care less that it's from 4 mos ago. It's apparently still an issue in the latest release.

[angelod1as]

Permissions Configured: { "permissions": { "allow": [ "", "Bash()", "curl()", "curl ", "curl", "Bash(curl)", "Bash(curl)", "Bash(curl:)", "Bash(curl -*)", "Bash(curl * *)", "Bash(curl * * *)", // ... plus 100+ specific curl patterns ], "deny": [] } }

@fwends – have you tried "Bash(curl:*)" (asterisk/wildcard after the colon)? That seems to work for me and follows the pattern that Claude Code uses in the settings.local.json if you select the "Yes, and don't ask again..." option for a given command prefix.

#3428 (comment) claims that claude does not support wildcards. But claude code seems to allow rules with wildcards itself when you select the option to allow things in the future. For example, claude code wrote this in my settings: "Bash(git commit:*)", Is that comment just wrong?

@nbrustein – it definitely supports wildcards... I think he just worded his comment poorly. He's basically saying that to allow all Bash commands (which for the record, I have no clue why you would want to do that), you would use "Bash" instead of "Bash:*". But for a specific command (e.g., if you want to allow all lsof commands), you can use wildcards to do that ("Bash(lsof:*)").

That's the same syntax I have for jq: "Bash(jq:*)"

That particular one doesn't work but others seem to work perfectly fine: "Bash(mv:)" "Bash(mkdir:)"

I tried:

Bash(jq)
Bash(jq *)
Bash(jq:*)

in project and user settings. Nothing worked.

[github-actions[bot]]

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.

[angelod1as]

Was this fixed? Why autoclose then?

[tonydehnke]

Still seems broken or at least buggy for me