[BUG] Agents and commands broken on nixos

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/4728
2. https://github.com/anthropics/claude-code/issues/4901

If your issue is a duplicate, please close it and 👍 the existing issue instead.

🤖 Generated with Claude Code

The plot thickens slightly...

export NIXPKGS_ALLOW_UNFREE=1
nix run github:NixOS/nixpkgs/nixos-unstable#claude-code --impure
> /agents

This still works on ubuntu

But it doesn't work on nixos.

If anyone can give me an idea what that /agents command is doing under the surface I'd be happy to help debug! I assume whatever is being executed assumes a certain filesystem which might explain why it's broken on nixos and the reports of the same on windows.

@commandodev try

strace -e trace=file -o /tmp/log.txt claude
/agents
Ctrl+D
grep agents /tmp/log.txt

This is my log, I have one global agent:

access("/home/osv/work/my/nixos-config/.claude/agents", F_OK) = -1 ENOENT (No such file or directory)
access("/home/osv/.claude/agents", F_OK) = 0
openat(AT_FDCWD, "/home/osv/.claude/agents/distel/meta-agent.md", O_RDONLY|O_CLOEXEC) = 33

expected access directory:
"/home/$HOME/.claude/agents"

@commandodev try `` strace -e trace=file -o /tmp/log.txt claude /agents Ctrl+D grep agents /tmp/log.txt ` This is my log, I have one global agent: ` access("/home/osv/work/my/nixos-config/.claude/agents", F_OK) = -1 ENOENT (No such file or directory) access("/home/osv/.claude/agents", F_OK) = 0 openat(AT_FDCWD, "/home/osv/.claude/agents/distel/meta-agent.md", O_RDONLY|O_CLOEXEC) = 33 `` expected access directory: "/home/$HOME/.claude/agents"

Thanks @osv I'll give that a go. Is yours working?

well well well:

❯ grep agents /tmp/log.txt
access("/home/ben/dev/missionctrl-infra/.claude/agents", F_OK) = 0
access("/home/ben/.claude/agents", F_OK) = 0
openat(AT_FDCWD, "\33[0m\33[35m/home/ben/dev/missionctrl-infra/.claude/agents/business-analyst-pa.md\33[0m", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "\33[0m\33[35m/home/ben/dev/missionctrl-infra/.claude/agents/nix-packaging-expert.md\33[0m", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "\33[0m\33[35m/home/ben/.claude/agents/business-analyst-pa.md\33[0m", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "\33[0m\33[35m/home/ben/.claude/agents/typescript-expert.md\33[0m", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "\33[0m\33[35m/home/ben/.claude/agents/nix-packaging-expert.md\33[0m", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

Somehow I've got color codes in the filenames that are being looked up

From claude:

The issue appears to be a bug in Claude itself where ANSI color codes are
getting mixed into file paths during the /agents command execution.

Looking at your config:

• Files exist in both directories correctly
• Your shell config uses eza with color icons but no unusual color

configurations

• Standard terminal environment (ghostty with proper TERM settings)

This is definitely a Claude bug where it's trying to colorize the output
for display but then using those colorized strings (with embedded ANSI
codes) as actual file paths for system calls.

Workarounds to try:

1. Disable colors temporarily:

NO_COLOR=1 claude

1. Set simpler TERM:

TERM=xterm claude

1. Check Claude settings for color options:

claude config

env -i PATH="$PATH" HOME="$HOME" TERM=dumb claude

When I run like this /agents works as expected

Lol, weird issue. I'm running claude from npm on Nixos,
node js: v22.14.0
claude: 1.0.67

Terminal ghostty works:
echo $TERM
xterm-ghostty

Usually I'm using urxvt - rxvt-unicode-256color

I found the fix finally!

Tracked it down to a ripgrep config that has --color=always. I changes this to color=auto and it now works fine.

I'm still finding it broken on NixOS, and I dont use rg.

The paths appearing from strace are correct.

grep agents /tmp/log.txt
faccessat(AT_FDCWD, "/home/rorychatterton/repos/myproject/.claude/agents", F_OK) = 0
faccessat(AT_FDCWD, "/home/rorychatterton/.claude/agents", F_OK) = 0

It isn't working for me through the NixPkgs version, i.e. nix run github:NixOS/nixpkgs/nixos-unstable#claude-code --impure:

 Claude CLI Diagnostic
 Currently running: unknown (1.0.65)
 Path: /nix/store/rpk03376gp4vrjrahx11ncr50ji6cvhw-nodejs-20.19.4/bin/node
 Invoked: /nix/store/5mrnfls4vvl5c7qcjzl5gplzb25wv2dl-claude-code-1.0.65/lib/node_modules/@anthropic-ai/claude-code/cli.js
 Config install method: unknown
 Auto-updates enabled: disabled
 Press Enter to continue…

or via Pnpm (v1.0.65 / Node 22)

 Diagnostics
 └ Currently running: unknown (1.0.69)
 └ Path: /nix/store/z9l0fzb0v930ysr1zc9frrjwi6q07cy7-nodejs-22.16.0/bin/node
 └ Invoked: /home/rorychatterton/.local/share/pnpm/global/5/.pnpm/@anthropic-ai+claude-code@1.0.69/node_modules/@anthropic-ai/claude-code/cli.js
 └ Config install method: unknown
 └ Auto-updates enabled: disabled

Debug logs show nothing.

Running with
NO_COLOR etc changes nothing (given that the paths are already correct).

The agents were generated by claude, but I've also tried copy/pasting some working known examples off the netw ith no dice

@rorychatterton , @commandodev btw, I'm not sure if this can help you, but you can check in your bash/zsh init for $CLAUDECODE and skip --color=always (maybe you have alias?) Below is what I'm using to make direnv works in claude code "bash" tool:

programs.zsh.envExtra = ''
        # Claude Code direnv integration
        # Also need mkdir -p ~/.config/direnv
        # touch ~/.config/direnv/direnv.toml
        # because there is a bug that causes DIRENV_LOG_FORMAT to be ignored if the config
        # file does not exist

        if command -v direnv >/dev/null; then
          if [[ ! -z "$CLAUDECODE" ]]; then
            eval "$(direnv hook zsh)"
            eval "$(DIRENV_LOG_FORMAT= direnv export zsh)"  # Need to trigger "hook" manually
          fi
        fi
      '';

You can review your zsh/bash setup for ripgrep? or set NO_COLOR if $CLAUDECODE is defined?

@osv Thanks OSV, I don't use RG (Although now I have RG FOMO and will need to install it). I've confirmed it isn't referenced in my configuration, and running env -i PATH="$PATH" HOME="$HOME" TERM=dumb claude doesn't work.

I tried your envextra (along with creating direnv.toml), but still having the same issue.

% printenv | grep CLAUDECODE
% printenv | grep color
TERM=xterm-256color
% which rg
rg not found

<img width="726" height="598" alt="Image" src="https://github.com/user-attachments/assets/56b7fdb5-9da5-42c4-9fc4-0ed0d9dc6453" />

Unsure whether to create another thread as the OPs original issue seems solved, but I'm having the same symptoms, albeit seemingly different cause.

Still broken in 1.0.72.

Here's one more case things could fail. For me, Claude Code is trying to execve ~/.claude/local/node_modules/@anthropic-ai/claude-code/vendor/ripgrep/x64-freebsd/rg, which does not exist.

We don't currently ship built-in ripgrep for platforms besides darwin, linux, and win32. You should be able to work around this by installing ripgrep yourself and passing env var USE_BUILTIN_RIPGREP=0 to claude.

@jxy ~That was it for me! As my installation didn't have ripgrep installed at all, the Agents was silently failing. By adding Ripgrep, the USE_BUILTIN_RIPGREP=0 variable & color=auto, agents are now working for me on Nix. Ripgrep may need to be added as a dependency to the CC Nix Package.~

Edit: Actually, I just checked the ripgrep that's included with the package in the /vendor npm folder, and it works fine (I assume it's statically bound?) when calling it directly.

I've removed ripgrep entirely from my nixos config, and that env variable, and its now working for me. Must have been sorted by a recent update.

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.

This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.

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.