[BUG]

Resolved 💬 5 comments Opened Jan 7, 2026 by dwalend Closed Feb 21, 2026

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?

Bash permission patterns with wildcards (e.g., Bash(say:*)) in .claude/settings.local.json do not work. Commands matching these patterns still require manual approval, even though they're explicitly allowed in the configuration.

This blocks legitimate use cases like audio notifications for long-running tasks, which is also an accessibility concern for users who cannot constantly monitor visual output. Given Claude's 5-20 minute time scale I use this so that I can engage in other tasks while Claude is running. Without an audio prompt I gain almost nothing using Claude do my typing at about the same pace as I do it myself.

What Should Happen?

When Bash(say:*) is added to the "allow" list in settings.local.json, any say command should execute without prompting for approval.

Error Messages/Logs

No error - the command simply prompts for approval instead of auto-approving.

Steps to Reproduce

  1. Add to .claude/settings.local.json:

{
"permissions": {
"allow": ["Bash(say:*)"]
}
}

  1. Start Claude Code
  1. Ask Claude to run: say "test complete"
  1. Observe that approval is still required despite the wildcard permission

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.0.76 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

IntelliJ IDEA terminal

Additional Information

Related closed issues: #3428, #10467, #6631

Accessibility impact: Audio notifications are critical for users with visual impairments or those who cannot constantly monitor a terminal. The say command is read-only and harmless—blocking wildcard approval creates an unnecessary barrier for developers who depend on non-visual feedback.

No practical workaround exists. Users must either approve every notification manually (defeating the purpose), skip notifications entirely, or pre-add every specific phrase (defeating the purpose). Unix beep commands are also disabled.

Please actually fix this bug instead of ignoring it quietly for a week, then closing it. #3428 was opened last July, clearly this bug, and never fixed. That's an unacceptable process for a product that costs actual money but fails to deliver.

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗