[FEATURE] Use git -C <path> instead of cd <path> && git ...

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

Feature Request: Use git -C <path> instead of cd <path> && git ...

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single feature request

Summary

When Claude Code needs to run a git command in a directory other than the current working directory, it constructs compound shell commands like:

cd /path/to/repo && git ls-remote --tags origin

This triggers the hardcoded "bare repository attack" security warning, which cannot be bypassed even with Bash(**) in the user's settings.json permissions. The user must manually approve every such command.

Proposed Solution

Use git's built-in -C flag to specify the working directory:

git -C /path/to/repo ls-remote --tags origin

This is a single command — no cd, no &&, no compound shell expression — so it does not trigger the bare repository attack heuristic. It is cleanly matched by existing Bash(**) or Bash(git *) permission patterns.

The -C flag has been available since git 1.8.5 (November 2013) and is supported on all modern platforms.

Why This Matters

• Users who have explicitly granted Bash(**) permission expect all bash commands to run without prompts
• The current compound command pattern bypasses user-configured permissions via a hardcoded security check
• The fix is trivial and backward-compatible
• No security is lost — git -C runs in the specified directory just like cd && git does, but without invoking a compound shell expression

Steps to Reproduce

1. Set "Bash(**)" in ~/.claude/settings.json permissions allow list
2. Ask Claude Code to check tags on a repo in a different directory
3. Claude Code generates: cd /path/to/repo && git ls-remote --tags origin
4. User is prompted to approve despite Bash(**) permission

Expected Behavior

Claude Code generates git -C /path/to/repo ls-remote --tags origin and the command runs without prompting, respecting the user's configured permissions.

Proposed Solution

Feature Request: Use git -C <path> instead of cd <path> && git ...

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single feature request

Summary

When Claude Code needs to run a git command in a directory other than the current working directory, it constructs compound shell commands like:

cd /path/to/repo && git ls-remote --tags origin

This triggers the hardcoded "bare repository attack" security warning, which cannot be bypassed even with Bash(**) in the user's settings.json permissions. The user must manually approve every such command.

Proposed Solution

Use git's built-in -C flag to specify the working directory:

git -C /path/to/repo ls-remote --tags origin

This is a single command — no cd, no &&, no compound shell expression — so it does not trigger the bare repository attack heuristic. It is cleanly matched by existing Bash(**) or Bash(git *) permission patterns.

The -C flag has been available since git 1.8.5 (November 2013) and is supported on all modern platforms.

Why This Matters

• Users who have explicitly granted Bash(**) permission expect all bash commands to run without prompts
• The current compound command pattern bypasses user-configured permissions via a hardcoded security check
• The fix is trivial and backward-compatible
• No security is lost — git -C runs in the specified directory just like cd && git does, but without invoking a compound shell expression

Steps to Reproduce

1. Set "Bash(**)" in ~/.claude/settings.json permissions allow list
2. Ask Claude Code to check tags on a repo in a different directory
3. Claude Code generates: cd /path/to/repo && git ls-remote --tags origin
4. User is prompted to approve despite Bash(**) permission

Expected Behavior

Claude Code generates git -C /path/to/repo ls-remote --tags origin and the command runs without prompting, respecting the user's configured permissions.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Feature Request: Use git -C <path> instead of cd <path> && git ...

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single feature request

Summary

When Claude Code needs to run a git command in a directory other than the current working directory, it constructs compound shell commands like:

cd /path/to/repo && git ls-remote --tags origin

This triggers the hardcoded "bare repository attack" security warning, which cannot be bypassed even with Bash(**) in the user's settings.json permissions. The user must manually approve every such command.

Proposed Solution

Use git's built-in -C flag to specify the working directory:

git -C /path/to/repo ls-remote --tags origin

This is a single command — no cd, no &&, no compound shell expression — so it does not trigger the bare repository attack heuristic. It is cleanly matched by existing Bash(**) or Bash(git *) permission patterns.

The -C flag has been available since git 1.8.5 (November 2013) and is supported on all modern platforms.

Why This Matters

• Users who have explicitly granted Bash(**) permission expect all bash commands to run without prompts
• The current compound command pattern bypasses user-configured permissions via a hardcoded security check
• The fix is trivial and backward-compatible
• No security is lost — git -C runs in the specified directory just like cd && git does, but without invoking a compound shell expression

Steps to Reproduce

1. Set "Bash(**)" in ~/.claude/settings.json permissions allow list
2. Ask Claude Code to check tags on a repo in a different directory
3. Claude Code generates: cd /path/to/repo && git ls-remote --tags origin
4. User is prompted to approve despite Bash(**) permission

Expected Behavior

Claude Code generates git -C /path/to/repo ls-remote --tags origin and the command runs without prompting, respecting the user's configured permissions.

Additional Context

_No response_