Custom slash commands behave unpredictably compared to just pasting in a formatted prompt

Resolved 💬 5 comments Opened May 11, 2025 by djaddis Closed Jan 3, 2026

Bug Description
Custom slash commands with arguments behave unreliably compared to simply pasting in formatted prompts

Environment Info

  • Platform: macos
  • Terminal: iTerm.app
  • Version: 0.2.107
  • Feedback ID: 69025579-bd4d-429c-ad67-4e1f9a59d6ec

With a simple context priming slash command like this:

Simply explore the codebase to understand everything we need to know to answer the <user_query>. Don't actually write any code or plan changes, just find and read all the relevant files and explain why they are important.

Consider relevant classes and functions, depdencies and usages, and any other context that might be useful for the user to know.

<user_query>
$ARGUMENTS
</user_query>

And then implementing it like:
/user:context_prime "We need to refactor our module structure to make it less coupled"

Claude will ignore the command and just start trying to implement the request. It's possible to get it to listen with enough prompt engineering e.g. providing multiple examples, but even adding something like this it still fails:

<important_rules>
**IMPORTANT: DO NOT ATTEMPT TO PLAN THE CHANGES, WRITE ANY CODE, OR ANSWER THE QUERY YOURSELF, YOU SHOULD ONLY FIND AND READ RELEVANT FILES FOR CONTEXT**
</important_rules>

This is in contrast to simply formatting the prompt with the request and pasting it in, which is adhered to every time even with minimal effort put into the prompt.

This is not a one-off example, I've found this with multiple different slash commands. They are very unreliable compared to a pasted prompt.

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:882:11)\n    at execSync (node:child_process:954:15)\n    at PW (file:///Users/dewiaddisedited/.nvm/versions/node/v23.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:634:3394)\n    at file:///Users/dewiaddisedited/.nvm/versions/node/v23.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:564:13915\n    at D (file:///Users/dewiaddisedited/.nvm/versions/node/v23.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:503:12907)\n    at jW (file:///Users/dewiaddisedited/.nvm/versions/node/v23.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:564:13436)\n    at XA6 (file:///Users/dewiaddisedited/.nvm/versions/node/v23.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:2049:21067)\n    at file:///Users/dewiaddisedited/.nvm/versions/node/v23.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:2192:639","timestamp":"2025-05-11T09:03:34.426Z"},{"error":"Error: Request was aborted.\n    at X3.makeRequest (file:///Users/dewiaddisedited/.nvm/versions/node/v23.10.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:696:7727)\n    at processTicksAndRejections (node:internal/process/task_queues:105:5)\n    at runNextTicks (node:internal/process/task_queues:69:3)\n    at process.processTimers (node:internal/timers:543:9)","timestamp":"2025-05-11T09:03:41.319Z"}]

View original on GitHub ↗

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