claude-code icon indicating copy to clipboard operation
claude-code copied to clipboard

[FEATURE] Add tool alias configuration for modern CLI alternatives

Open PaulRBerg opened this issue 3 months ago • 5 comments

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Many developers prefer modern CLI tools over legacy alternatives:

  • fd instead of find
  • rg (ripgrep) instead of grep
  • bat instead of cat
  • eza instead of ls

Currently, there's no easy way to configure Claude Code to automatically use these alternatives. Users must rely on workarounds like:

  1. Adding instructions to CLAUDE.md (soft guidance, not enforced)
  2. Creating custom PreToolUse hooks to block legacy commands
  3. Using permission deny rules (bypassable with prefix matching)

Additionally, piped commands like find ... | head still trigger permission requests even when both find and head are individually allowlisted, because piped commands are treated as a distinct security category.

Proposed Solution

Add a toolAliases configuration option in settings.json that automatically maps legacy tools to modern alternatives:

{
  "toolAliases": {
    "find": "fd",
    "grep": "rg",
    "cat": "bat",
    "ls": "eza"
  }
}

When Claude generates a command using find, it would automatically be translated to the equivalent fd syntax. This would:

  1. Be declarative and easy to configure
  2. Apply globally without per-project setup
  3. Handle the command translation automatically (not just block and suggest)

Alternative Solutions

  1. PreToolUse hooks: Works but requires Python scripting and manual setup
  2. CLAUDE.md instructions: Provides guidance but no enforcement
  3. Permission deny rules: Can block commands but doesn't suggest alternatives

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

  1. User adds "toolAliases": { "find": "fd" } to ~/.claude/settings.json
  2. User asks Claude to "find all TypeScript files in src/"
  3. Claude generates fd -e ts src/ instead of find src/ -name "*.ts"
  4. No permission prompts, no hooks required, just works

Additional Context

Related issues:

  • Piped commands permission bug: https://github.com/anthropics/claude-code/issues/1271
  • Bash wildcard permission issue: https://github.com/anthropics/claude-code/issues/3428

This would align well with the growing trend of modern CLI tools that are faster, more user-friendly, and respect .gitignore by default.

PaulRBerg avatar Nov 25 '25 16:11 PaulRBerg

This can be achieved using a prompt in CLAUDE.md, I have this in my global CLAUDE.md

### Preferred Command-Line Tools

This machine has modern alternatives to traditional Unix tools installed, ALWAYS prefer using them over the traditional ones unless there's a strong reason not to.

#### Search Tools
- **ripgrep (`rg`)** instead of `grep`:
  - Faster recursive search with smart defaults
  - Automatically respects `.gitignore`
  - Example: `rg "pattern"` instead of `grep -r "pattern"`

- **fd** instead of `find`:
  - Faster file search with intuitive syntax
  - Respects `.gitignore` by default
  - Example: `fd "filename"` instead of `find . -name "filename"`

### Available Tools

**GitHub**: `gh` - always use for GitHub operations (PRs, issues, repos, actions, API)

**File viewing**:
- `bat` - syntax-highlighted cat
- `eza` - modern ls with git integration
- `glow` - render markdown in terminal

**Data processing**:
- `jq` - JSON processor
- `yq` - YAML processor (same syntax as jq)

**Search & selection**:
- `rg` (ripgrep) - fast grep
- `fd` - fast find
- `fzf` - fuzzy finder for interactive selection

**Git**:
- `delta` - better diff viewer
- `lazygit` - TUI for complex git operations

**System**:
- `duf` - disk usage (modern df)
- `ncdu` - interactive disk usage explorer
- `hyperfine` - benchmarking

**HTTP**: `http` / `https` (httpie) - user-friendly curl alternative

**File watching**: `entr` - run commands when files change (e.g., `ls *.py | entr pytest`)

**macOS**: `pbcopy`/`pbpaste` (clipboard), `open` (open files/URLs/apps)

**Note**: When asked to "copy" something, pipe it through `pbcopy` to put it on the clipboard.

AbdelrahmanHafez avatar Dec 11 '25 11:12 AbdelrahmanHafez

@AbdelrahmanHafez the problem with putting this information in CLAUDE.md is that you're polluting the context and providing Claude with contradictory instructions - in Claude Code's system prompts, there are rules for using certain tools and certain CLIs. See tweakcc.

The only efficient way to swap out the CLIs used by Claude Code is to make them configurable through bespoke settings, as I've suggested in the OP.

PaulRBerg avatar Dec 11 '25 11:12 PaulRBerg

@PaulRBerg

Additionally, piped commands like find ... | head still trigger permission requests even when both find and head are individually allowlisted, because piped commands are treated as a distinct security category.

BTW, I solved the piped commands problem with claude-code-plus. It's functional, and I've been using it for a couple of weeks with a significant productivity boost. Still needs some polish, though.

When Claude generates a command using find, it would automatically be translated to the equivalent fd syntax. This would:

Be declarative and easy to configure Apply globally without per-project setup Handle the command translation automatically (not just block and suggest)

the problem with putting this information in CLAUDE.md is that you're polluting the context and providing Claude with contradictory instructions

It's unclear to me what you're proposing here. It feels like you have multiple proposals:

  1. Claude should generate fd instead of find, which can be achieved via CLAUDE.md or by prompting the model under the hood to prefer modern tools.

  2. Claude presents find to the user but actually executes fd under the hood. I'd be concerned about this because almost none of these tools are drop-in replacements; they have different APIs and flags. Translating from one to another would require either an LLM call or complex and fragile programmatic translation. There's also the transparency concern: telling the user we'll execute one thing while actually executing another.

AbdelrahmanHafez avatar Dec 11 '25 11:12 AbdelrahmanHafez