[BUG] `/ralph-wiggum:ralph-loop` slash command fails permission check

[wanderingnature]

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?

Summary

The /ralph-wiggum:ralph-loop slash command consistently fails with a bash permission error, even when valid permission patterns are configured. The command works when Claude falls back to calling the setup script directly via Bash().

Environment

• Claude Code v2.0.76
• Ralph Wiggum plugin (commit 15b07b46dab3)
• Ubuntu Linux

Steps to Reproduce

1. Configure .claude/settings.json with permission pattern:

   {
     "permissions": {
       "allow": [
         "Bash(:*/ralph-wiggum/:*)"
       ]
     }
   }
   

2. Run the slash command:

   /ralph-wiggum:ralph-loop "Simple task" --completion-promise "DONE" --max-iterations 5
   

3. Observe permission error

Expected Behavior

The slash command should execute the setup script with proper permission matching.

Actual Behavior

The command fails with:

Error: Bash command permission check failed for pattern "```!
"/home/nicholas/.claude/plugins/cache/claude-plugins-official/ralph-wiggum/15b07b46dab3/scripts/setup-ralph-loop.sh" "Simple task" --completion-promise "DONE" --max-iterations 5
```": This command requires approval

Note the triple backticks and ! wrapping the command in the error output. This suggests the plugin is formatting the bash command incorrectly before passing it to Claude Code's permission checker.

Workaround

When the slash command fails, Claude can retry by calling the script directly via Bash():

Bash("/home/nicholas/.claude/plugins/cache/claude-plugins-official/ralph-wiggum/15b07b46dab3/scripts/setup-ralph-loop.sh" "Simple task" --completion-promise "DONE" --max-iterations 5)

This works correctly and triggers the normal approval flow.

Root Cause

The issue is in commands/ralph-loop.md. The original file uses a ```! code block syntax to specify bash execution:

Original (broken):

---
description: "Start Ralph Wiggum loop in current session"
argument-hint: "PROMPT [--max-iterations N] [--completion-promise TEXT]"
allowed-tools: ["Bash(${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh)"]
hide-from-slash-command-tool: "true"
---

# Ralph Loop Command

Execute the setup script to initialize the Ralph loop:

` ` `!
"${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh" $ARGUMENTS
` ` `

...

The ```! syntax appears to be intended as a plugin directive meaning "execute this command." However, Claude Code's permission system receives the literal string including the backticks and ! rather than just the command inside. The permission checker therefore sees:

```!
"/path/to/script.sh" "args"

Instead of:

"/path/to/script.sh" "args"

This causes all permission patterns to fail matching, regardless of how they're configured.

### Is This a Plugin Bug or Claude Code Bug?

**This is a plugin authoring bug**, not a Claude Code bug. The ` ```! ` syntax is either:
- Undocumented/unsupported
- Deprecated
- Never worked as intended

The correct approach is to instruct Claude to invoke the `Bash()` tool directly in the command body, which the plugin's `allowed-tools` frontmatter already permits.

## Tested Permission Patterns (All Failed with Original Plugin)

- `Bash(*/ralph-wiggum/*/scripts/*.sh:*)`
- `Bash(*/ralph-wiggum/*/scripts/*.sh *)`
- `Bash(:*setup-ralph-loop.sh:*)`
- `Bash(:*/ralph-wiggum/:*)`

None of these patterns match because the command string is malformed before reaching the permission checker.

## Fix

Replace the contents of `commands/ralph-loop.md` with:

```markdown
---
description: "Start Ralph Wiggum loop in current session"
argument-hint: "PROMPT [--max-iterations N] [--completion-promise TEXT]"
allowed-tools: ["Bash(${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh:*)"]
hide-from-slash-command-tool: "true"
---

# Ralph Loop Command

Execute this bash command to initialize the Ralph loop:

Bash("${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh" $ARGUMENTS)

Please work on the task. When you try to exit, the Ralph loop will feed the SAME PROMPT back to you for the next iteration. You'll see your previous work in files and git history, allowing you to iterate and improve.

CRITICAL RULE: If a completion promise is set, you may ONLY output it when the statement is completely and unequivocally TRUE. Do not output false promises to escape the loop, even if you think you're stuck or should exit for other reasons. The loop is designed to continue until genuine completion.

Changes made:

1. Removed ```! code block wrapper - this was being passed literally to the permission checker
2. Added :* to allowed-tools pattern (Bash(${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh:*)) to permit any arguments to be passed to the script

Verified Working

After applying this fix, the slash command works correctly:

/ralph-wiggum:ralph-loop "Document the full generation process..." --completion-promise "GENERATION_DOCUMENTED" --max-iterations 8

The Ralph loop activates as expected without permission errors.

What Should Happen?

plugin should run

Error Messages/Logs

## Summary

The `/ralph-wiggum:ralph-loop` slash command consistently fails with a bash permission error, even when valid permission patterns are configured. The command works when Claude falls back to calling the setup script directly via `Bash()`.

## Environment

- Claude Code v2.0.76
- Ralph Wiggum plugin (commit 15b07b46dab3)
- Ubuntu Linux

## Steps to Reproduce

1. Configure `.claude/settings.json` with permission pattern:
   
   {
     "permissions": {
       "allow": [
         "Bash(:*/ralph-wiggum/:*)"
       ]
     }
   }
   

2. Run the slash command:
   
   /ralph-wiggum:ralph-loop "Simple task" --completion-promise "DONE" --max-iterations 5
   

3. Observe permission error

## Expected Behavior

The slash command should execute the setup script with proper permission matching.

## Actual Behavior

The command fails with:


Error: Bash command permission check failed for pattern "!
"/home/nicholas/.claude/plugins/cache/claude-plugins-official/ralph-wiggum/15b07b46dab3/scripts/setup-ralph-loop.sh" "Simple task" --completion-promise "DONE" --max-iterations 5
": This command requires approval


Note the **triple backticks and `!`** wrapping the command in the error output. This suggests the plugin is formatting the bash command incorrectly before passing it to Claude Code's permission checker.

## Workaround

When the slash command fails, Claude can retry by calling the script directly via `Bash()`:


Bash("/home/nicholas/.claude/plugins/cache/claude-plugins-official/ralph-wiggum/15b07b46dab3/scripts/setup-ralph-loop.sh" "Simple task" --completion-promise "DONE" --max-iterations 5)


This works correctly and triggers the normal approval flow.

## Root Cause

The issue is in `commands/ralph-loop.md`. The original file uses a ` ! ` code block syntax to specify bash execution:

**Original (broken):**

---
description: "Start Ralph Wiggum loop in current session"
argument-hint: "PROMPT [--max-iterations N] [--completion-promise TEXT]"
allowed-tools: ["Bash(${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh)"]
hide-from-slash-command-tool: "true"
---

# Ralph Loop Command

Execute the setup script to initialize the Ralph loop:

` ` `!
"${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh" $ARGUMENTS
` ` `

...


The ` ! ` syntax appears to be intended as a plugin directive meaning "execute this command." However, Claude Code's permission system receives the **literal string including the backticks and `!`** rather than just the command inside. The permission checker therefore sees:


!
"/path/to/script.sh" "args"



Instead of:

"/path/to/script.sh" "args"


This causes all permission patterns to fail matching, regardless of how they're configured.

### Is This a Plugin Bug or Claude Code Bug?

**This is a plugin authoring bug**, not a Claude Code bug. The ` ! ` syntax is either:
- Undocumented/unsupported
- Deprecated
- Never worked as intended

The correct approach is to instruct Claude to invoke the `Bash()` tool directly in the command body, which the plugin's `allowed-tools` frontmatter already permits.

## Tested Permission Patterns (All Failed with Original Plugin)

- `Bash(*/ralph-wiggum/*/scripts/*.sh:*)`
- `Bash(*/ralph-wiggum/*/scripts/*.sh *)`
- `Bash(:*setup-ralph-loop.sh:*)`
- `Bash(:*/ralph-wiggum/:*)`

None of these patterns match because the command string is malformed before reaching the permission checker.

## Fix

Replace the contents of `commands/ralph-loop.md` with:


---
description: "Start Ralph Wiggum loop in current session"
argument-hint: "PROMPT [--max-iterations N] [--completion-promise TEXT]"
allowed-tools: ["Bash(${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh:*)"]
hide-from-slash-command-tool: "true"
---

# Ralph Loop Command

Execute this bash command to initialize the Ralph loop:

Bash("${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh" $ARGUMENTS)

Please work on the task. When you try to exit, the Ralph loop will feed the SAME PROMPT back to you for the next iteration. You'll see your previous work in files and git history, allowing you to iterate and improve.

CRITICAL RULE: If a completion promise is set, you may ONLY output it when the statement is completely and unequivocally TRUE. Do not output false promises to escape the loop, even if you think you're stuck or should exit for other reasons. The loop is designed to continue until genuine completion.


**Changes made:**
1. Removed ` ! ` code block wrapper - this was being passed literally to the permission checker
2. Added `:*` to `allowed-tools` pattern (`Bash(${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh:*)`) to permit any arguments to be passed to the script

## Verified Working

After applying this fix, the slash command works correctly:


/ralph-wiggum:ralph-loop "Document the full generation process..." --completion-promise "GENERATION_DOCUMENTED" --max-iterations 8


The Ralph loop activates as expected without permission errors.

Steps to Reproduce

run a basic loop: /ralph-wiggum:ralph-loop "Document the full generation process in docs/GENERATION.md. COMPLETION: docs/GENERATION.md covers workflow from input to outputs, all API calls, and all retry/regeneration options. GOALS: Trace workflow input to output. Document each Gemini API call. Document all regenerate endpoints. Show data flow and what saves at each step. SELF-CORRECT: Verify against api/main.py and roadless/*.py. ESCAPE: If stuck after 8 iterations, document blockers. Output GENERATION_DOCUMENTED when complete." --completion-promise "GENERATION_DOCUMENTED" --max-iterations 8

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.0.76

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

fix provided

[willsr]

same issue

[tberndt-ewolff]

same here. can confirm the fix works.

[wanderingnature]

Hey Antrhopic - it is a REAL ISSUE WITH AN EASY FIX, and today Claude and/or the plugin updated and overwrote my local fix with the same BUG. Now I have to apply the local fix AGAIN...

[amorriscode]

The issue was not related to the backticks but a fix is on main. Please update your plugin!

[jorgecolonconsulting]

@amorriscode updated the plugin, uninstalled/re-installed, restarted Claude Code every time, checked CC is updated (2.0.76). For the life of me I keep getting the same error.

Does Claude Code need a new version release bump in order to pick up your fixes?

[JeongJaeSoon]

Proposed Fix

I've identified the root cause and created a fix for this issue.

Problem Analysis

The backtick code block syntax (triple backticks with !) in plugins/ralph-loop/commands/ralph-loop.md is not being properly parsed by the permission checker. The backticks are included in the command string, causing pattern matching to fail against the allowed-tools configuration.

Solution

Replace the backtick code block with a direct Bash() function call:

Before:

```!
"${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh" $ARGUMENTS
```

After:

Bash("${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh" $ARGUMENTS)

Verification

• Tested locally using claude --plugin-dir flag
• Confirmed /ralph-loop skill executes without permission errors
• Setup script runs correctly and creates state file

PR (auto-closed)

https://github.com/anthropics/claude-plugins-official/pull/151

The PR was auto-closed by the external PR workflow. Could someone from the team review this fix and apply it to the ralph-loop plugin?

Note: PR #16522 added the :* pattern to allowed-tools, but didn't address the backtick parsing issue which is the actual root cause.

---

Alternatively, https://github.com/anthropics/claude-code/pull/16562 also looks like a good fix for related compatibility issues. I tested the portable shebang change locally and it works well too.

[JeongJaeSoon]

@amorriscode Could you review this proposed fix when you have a chance? Thanks!

[JeongJaeSoon]

Workaround (until the fix is released)

If you can't wait for the official fix, here's how I'm using it:

1. Clone the repository

gh repo clone anthropics/claude-plugins-official
cd claude-plugins-official/plugins/ralph-loop

2. Apply fixes to the plugin

Apply either Fix 1 or Fix 2 (both work):

Fix 1: Replace backtick code block with Bash() function call

Edit commands/ralph-loop.md line 12:

- ```!
- "${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh" $ARGUMENTS
- ```
+ Bash("${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh" $ARGUMENTS)

Fix 2: Use portable shebang (for NixOS/WSL2 compatibility)

Edit scripts/setup-ralph-loop.sh and hooks/stop-hook.sh:

- #!/bin/bash
+ #!/usr/bin/env bash

3. Create an alias

alias claude-ralph='claude --plugin-dir /path/to/claude-plugins-official/plugins/ralph-loop'

Now you can use claude-ralph to start Claude Code with the fixed ralph-loop plugin!

[leeovery]

Kind of hilarious but just ask ClaudeCode to fix it. Give him this issue and away you go. 😆

[JeongJaeSoon]

Haha, true! This image comes to mind 😄

[leeovery]

I can confirm though that CC made the changes proposed above and its working perfectly again :)

[MattPostlethwaite]

I can also confirm that the changes outlined by @JeongJaeSoon fixed the permissions issue

[ben-at-graphite]

@amorriscode - Looks like @JeongJaeSoon's fix works if we can apply that to this plugin at your convenience :) Thanks for maintaining this plugin!

[wanderingnature]

Yes, CC can indeed fix this and yes indeed CC did create the original bug report.

[github-actions[bot]]

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.