[BUG] Slash Commands not recognized

[natepiano]

Environment

• Platform (select one):
  • [X] Anthropic API
  • [ ] AWS Bedrock
  • [ ] Google Vertex AI
  • [ ] Other:
• Claude CLI version: 1.0.5
• Operating System: MacOS 15.5
• Terminal: iTerm2, Zed

Bug Description

slash commands from my .claude/commands folder no longer show up when i type a / they used to work great

Steps to Reproduce

1. run claude
2. type a / to bring up the list of commands

Expected Behavior

My custom slash commands are there

Actual Behavior

My custom slash commands aren't there

Additional Context

This is painful - I spent a lot of time on these and i like the usability

[thlandgraf]

I agree, this would be a huge QoL feature

[mattmaslin]

There is a previous open issues with work arounds for restoring slash commands:: #1212

[bcherny]

Hi! Are you setting the CLAUDE_CONFIG_DIR env var? And do you mean your ~/.claude/commands/, or the .claude/commands/ from the directory you're running claude in? If the latter, please share the full path.

[StephenBadger]

@bcherny I am experiencing this as well. WSL2 Ubuntu. Clearing the project folder from ~/.claude/projects/TheProjectIAmOn resolves the issue, but of course isn't ideal

[tbharthur]

I'm seeing this as well - it seems to only happen after purging worktrees

[95]

Also having this issue, even though root dir is recognized by Claude code

[MartinMinkov]

This behavior was happening for me to and just confirming that what @StephenBadger said worked for me to restore the slash commands.

Clearing the project folder from ~/.claude/projects/TheProjectIAmOn resolves the issue, but of course isn't ideal

[Vvkmnn]

Recycled the weird solve while debugging, left my notes on 1.0.44 (Claude Code) on macOS Sequoia 15.5 in case this helps anyone:

export CLAUDE_CONFIG_DIR=$HOME/.claude

In my version of a .zshrc only this worked (might reset default and delete any MCPs you have, back up Claude.) Got the idea from this solution, as there is nothing about this variable anywhere in the docs.

EDIT: Does not last, I ran /mcp again after adding one back with a custom commands, and they all came back. However, now that all my MCP servers work the commands are gone again, lol.

Need the MCP servers more so just gonna wait and see what happens. Explicitly ask claude to look for that command at a location when I need it, but it runs that command wrong.

Process:

1. Missing several custom commands in my ~/.claude/commands, realized while trying to use a worktree command and its missing
2. While fiddling with ~/.claude.json I find that I have the $XDG_CONFIG_HOME version of claude somehow, living in ~/.config/claude; decide to delete the conflicting folder
3. Custom commands still not working, and won't save to ~/.claude/commands or ./.claude/commands
4. Created an empty ~/.config/claude and the commands briefly came back
5. Found the above secret parameter and tried it; defaulted me back to regular claude and I lost all my MCPs in the process, but commands are back

Related: https://github.com/anthropics/claude-code/issues/1212 https://github.com/anthropics/claude-code/issues/1455 https://github.com/anthropics/claude-code/issues/2277#issuecomment-2997951442

[lightningRalf]

filed new issue.

[dicksontsai]

@lightningRalf Please file a new issue for what you're seeing. I would also recommend removing

  "env": {
	"CLAUDE_CONFIG_DIR": "$HOME/.claude/"
  }

from your config, since it is functionally the same as how we look for your user-level config dir by default.

[arathunku]

I'm running into the same problem. I ran claude with stace and it looks like ANSI escape sequences are used for accessing the files in my case.

getdents64(26, 0x10520ac0 /* 0 entries */, 32768) = 0
close(26)                               = 0
openat(AT_FDCWD, "\33[0m\33[35m/home/arathunku/.claude/commands/next.md\33[0m", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3415575, si_uid=1000, si_status=0, si_utime=0, si_stime=1 /* 0.01 s */} ---
read(5, "*", 1)                         = 1

It accesses other files OK, CLAUDE.md is read, and settings too, example:

openat(AT_FDCWD, "/home/arathunku/.claude/.claude.json", O_RDONLY|O_CLOEXEC) = 29

It's only a problem with commands.

[almirsarajcic]

I've had a similar issue where claude doctor showed everything working well with the native installer, but I couldn't find any custom commands. Fixed it by installing ripgrep using brew install ripgrep. https://docs.anthropic.com/en/docs/claude-code/troubleshooting#search-and-discovery-issues

[wuhao199368]

I just ran into the same issues and here's how I solved it:

1. Run "claude --debug" under the repository I was working on;
2. It suggest that "[DEBUG] Total plugin commands loaded: 0" and "Library not loaded: /opt/homebrew/opt/pcre2/lib/libpcre2-8.0.dylib", which means the missing "pcre2" library could be the reason of this issues;
3. I install pcre2 via "brew install pcre2" (May be you need to install brew first)

After the installation, this issues was solved. By the way, here's the environment information of my work space:

• MacOS Ventura 13.0.1
• Claude Code V1.0.108

Actually maybe you just need to run "claude --debug" and throw all the debug messages to Claude again, you can figure out what happen.

[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.

[woodwardjd]

I experienced similar symptoms today (claude code 2.0.76).

When running with --debug and reviewing the generated log file, I too noticed that the files in ~/.claude/commands it was complaining about being unable to read were colored when viewing the log file with less in my macOS iterm terminal. Noticing that a previous line in the debug log was testing whether or not rg (ripgrep) worked (successfully), I speculated that rg is being used to find files, and that rg's output had ansi color sequences in it, and that subsequent attempts to open the files returned by rg include those color sequences in the filenames, resulting in the ENOENT: no such file or directory errors in the debug logs.

I tracked down the problem in my installation being my global configuration of rg, as set with export RIPGREP_CONFIG_PATH=$HOME/.ripgreprc to point to ~/.ripgreprc, with --color always.

Removing this configuration resolved claude code's inability to read the slash command files, and now the slash commands appear as expected.

While I wouldn't say this is a bug in claude code, claude code could be extended to check for leading/trailing ansi color sequences in the outputs it gets from rg, and removing them before further processing. Or, figure out if there's a way to force it to not output color even when the user has that specified in ~/.ripgreprc. I was unable to find a way to do that in the 60 seconds tried.