[BUG] Custom slash commands can't request the user's permission to execute bash scripts

Sorry for the trouble. You need to add it to the allowed-tools frontmatter. We will improve the documentation and error messaging with v1.0.54.

---
allowed-tools: Bash
description: Enable Claude Code phone notifications
---

!`~/.claude/bin/claude-phone-on`

Thanks for the quick response, but that didn't solve the problem.

I tried to simplify things by creating a /phone-status slash command in ~/.claude/commands with phone-status.md:

---
allowed-tools: bash
description: Check Claude Code phone notification status
---

!`./claude-phone-status`

After making that change, I restarted Claude Code. Here's the transcript:

> /phone-status is running…
  ⎿  Allowed 1 tools for this command

⏺ I'll help you check the phone status in the system. Let me search for information about phone-related functionality in the codebase.

⏺ Task(Search for phone status functionality)
  ⎿  Search(pattern: "**/*telecom*.rb")
     Found 41 files (ctrl+r to expand)
     +1 more tool use
  ⎿  No (tell Claude what to do differently)

As you can see, Claude did not understand the command as a simple hand-off to bash, but instead started examining the codebase for references to phones.

I'd re-open the issue if I could.

Can you try capitalizing Bash?

I did that first, since that's how you indicated. It didn't work. The transcript I sent was from a later attempt.

I'm on macOS so using zsh. I've tried zsh and Zsh, too.

Each time, I get something a lot like this:

> /phone-status is running…
  ⎿  Allowed 1 tools for this command

⏺ I'll help you update the primary phones in the CRM system. Let me start by examining the script you've created to understand what needs to be done.
  ⎿  Interrupted by user

I found that if the parent project doesn't already allow for "Bash" in its allowed tools, it is true that the wrapped commands can't do it or request permissions.

Based on this guidance, and at Claude's suggestion, I created .claude_config.json in the .claude directory in my app root:

{
  "toolChoice": {
    "allowedTools": [
      "bash",
      "edit",
      "grep",
      "list",
      "read",
      "task",
      "write"
    ]
  }
}

After doing that, I still received this error:

> /phone:on
  ⎿  Error: Bash command permission check failed for pattern "!`~/.claude/bin/claude-phone-on`": Claude requested permissions to use Bash, but you haven't granted it yet.

So I used /permissions to enable:

Bash(~/.claude/bin/claude-phone-on)

After that, I was back to square one:

> /phone:on is running…

⏺ I'll help you implement a feature to track user activity with the membership created date. Let me start by understanding the current structure and then plan the implementation.
  ⎿  Interrupted by user

I can't begin to guess where that last hallucination came from. Previous such episodes usually elicited intentions that were at least phone-related in some way.

PS: Capitalizing "Bash" in .claude/.claude_config.json didn't help either.

Not sure in which of the many identical issues to put this, so I'm hoping someone catches it here:
I believe the issue stems from inconsistent expansion of the ~ sign (home folder).
Sometimes Claude will try to read from the relative path (~/someFolder), and when you approve the action, the actual permission written to the settings will be "Read(/home/<username>/someFolder/**)"
But when Claude tries again to read from ~/someFolder, it will not match the rule in the settings JSON.
Manually adding the relative path (as ~/someFolder) to permissions (from Claude /permissions or directly to settings json) will resolve the issue.

I believe a proper solution would be for claude to identify home-folder paths, and add both the relative and absolute paths to the 'allowed' list, so both versions will work (or for Claude to always expand homefolder paths behind the scenes?)

Based on this guidance, and at Claude's suggestion, I created .claude_config.json in the .claude directory in my app root: { "toolChoice": { "allowedTools": [ "bash", "edit", "grep", "list", "read", "task", "write" ] } } After doing that, I still received this error: `` > /phone:on ⎿  Error: Bash command permission check failed for pattern "!~/.claude/bin/claude-phone-on": Claude requested permissions to use Bash, but you haven't granted it yet. ``

What worked for me what to specify on my project local settings .claude/settings.local.json the following:

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

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.

I got the same error as well:

Error: Bash command permission check failed for pattern "```!

The fix I did was to add Bash (without any arguments) to my local .claude/settings.local.json file, like this:

{
  "permissions": {
    "allow": [
      "Bash"
    ]
  },
  "enabledPlugins": {
    "ralph-wiggum@claude-plugins-official": true
  }
}

getting this even with ⎿ Error: Bash command failed for pattern "```!

"permissions": {
"allow": [
"Bash"
]

@grmkris you need to restart CC

Adding Bash(*) is a really risky way to fix this issue. Seems like that would give permission to run any bash command which could be disastrous if it attempted to run something destructive.

Shouldn't Claude Code be asking for the permission rather than reporting:

  ⎿  Error: Bash command permission check failed for pattern "```!
  ⎿  "/Users/name/.claude/plugins/cache/claude-plugins-official/ralph-wiggum/bf48ae6c75e7/scripts/setup-ralph-loop.sh" $ARGUMENTS
  ⎿  ```": This command requires approval

Feels like I shouldn't need to go into the permission directory and manually add it for this to work--I also did this manually into the permission settings directory and it did not work as well to resolve the plugin failing to execute

What worked for me:

 Bash(/Users/me/.claude/plugins/cache/claude-plugins-official/ralph-loop/b97f6eadd929/scripts/setup-ralph-loop.sh:*)

What worked for me: `` Bash(/Users/me/.claude/plugins/cache/claude-plugins-official/ralph-loop/b97f6eadd929/scripts/setup-ralph-loop.sh:*) ``

Works, thank you 👍🏻

Additional Evidence: Tool:Bash:slashCommand:* Syntax Also Fails

I'm experiencing the same issue with slash commands not properly handling Bash permissions. I've read through
the existing workarounds in this thread, but I wanted to report that the documented permission syntax also
doesn't work.

Setup

Claude Code Version: 1.0.88
OS: Linux (WSL2)
Backend: AWS Bedrock

Configuration Attempted

Based on the documented permission syntax, I tried configuring auto-approval for Bash commands in slash
commands via settings.json:

{
"permissions": {
"allow": [
"Tool:Bash:slashCommand:*"
]
}
}

This is different from the Bash(*) workaround mentioned in earlier comments - this uses the specific slash
command scoping syntax that should theoretically only affect Bash commands executed within slash commands.

What I Discovered

The permission configuration is being recognized by the system (confirmed by checking the assistant's system
prompt which shows: "You can use the following tools without requiring user approval:
Tool:Bash:slashCommand:*"), but it's not being enforced during execution.

When I run a slash command that uses Bash:

1. ✅ The slash command is recognized and starts running
2. ✅ The permission rule is loaded (visible in system prompt)
3. ❌ User is still prompted to approve Bash execution
4. ❌ The permission rule is completely ignored

Implications

This adds to the evidence that the bug is in the permission enforcement layer:

• Unlike the Bash(*) workaround which some users report working (but is overly permissive), the proper scoped

syntax Tool:Bash:slashCommand:* doesn't work at all

• The permission system reads and acknowledges the rule but fails to apply it during tool execution
• This suggests the permission check happens in a context where the slash command scope information is lost

or not properly matched

This might help narrow down where in the codebase the bug exists - likely in the permission enforcement logic
where the tool use context isn't being properly compared against the slashCommand:* pattern.