### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement When running /security-review in a repository where origin/HEAD is not set, the command fails immediately with a cryptic Git error: ```bash Error: Bash command failed for pattern "!`git diff --merge-base origin/HEAD`"

[FEATURE] Improve error message when origin/HEAD is not set for /security-review command

Status Open

Maintainer reply None cached

Activity 5 comments · opened Dec 2, 2025

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

When running /security-review in a repository where origin/HEAD is not set, the command fails immediately with a cryptic Git error:

Error: Bash command failed for pattern "!`git diff --merge-base origin/HEAD`": [stderr] fatal: ambiguous argument 'origin/HEAD': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'

This error doesn't indicate what the actual problem is or how to fix it. Users unfamiliar with Git internals may not understand that they simply need to set origin/HEAD.

Proposed Solution

Detect missing origin/HEAD before running the diff command
Provide a helpful error message that explains the issue and suggests the fix:

Error: origin/HEAD is not set. This is required for /security-review to compare changes.

To fix this, run:
     git remote set-head origin -a

   Then try /security-review again.

Optionally: Automatically fall back to origin/main or origin/master if origin/HEAD is not set

Alternative Solutions

Current workaround is to manually run:

git remote set-head origin -a

This works, but requires users to search for the solution externally.

Priority

Low - Nice to have

Feature Category

CLI commands and flags

Use Case Example

User clones a repository or sets up a new project with git init + git remote add origin
User runs /security-review to check for vulnerabilities
Command fails with unclear error about origin/HEAD
User spends time searching online for the solution
Expected: Clear error message with one-liner fix command

Additional Context

This is a common Git configuration issue, especially for newly cloned repos or repos set up manually
The fix is trivial (git remote set-head origin -a), but the current error message provides no guidance
Similar issue reported in a Japanese blog post encountering the same error: https://note.com/munakata_souri/n/n346c43c49b9a

View original on GitHub ↗

5 Comments

github-actions[bot] · 8 months ago

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.

vincentfretin · 7 months ago

I have the same issue with Claude Code 2.1.9
Feedback ID: 8d8e822a-9693-4da1-a577-4438e5a89224
I had indeed no clue that I had to run git remote set-head origin -a to make it work.

officialankan · 6 months ago

does this mean i have to have a remote before running /security-review? why?

kushbuddha · 1 month ago

Still reproduces on v2.1.211 (macOS, July 2026) — ~7 months after this was
first reported.

Answering @officialankan's question above, since it's the crux and I don't think
it's been addressed: yes, today you effectively must have a remote, and the
usual workaround doesn't help if you don't have one.

Why: it's not one call, it's three

/security-review's prompt interpolates origin/HEAD in three separate !
patterns:

GIT STATUS:      !`git status`
FILES MODIFIED:  !`git diff --name-only origin/HEAD...`
COMMITS:         !`git log --no-decorate origin/HEAD...`
DIFF CONTENT:    !`git diff origin/HEAD...`

Any failing ! pattern aborts at load time, so the skill body never runs.
It isn't that the review is degraded — the command dies before it starts.

The gap in the standard workaround

The advice in this thread is git remote set-head origin -a. That works only
if a remote exists — it queries the remote for its default branch. In a repo
created with git init and never pushed, there is no remote to ask, so that
command fails too and the user is stuck with no documented path.

Minimal repro (no remote, 4 commands):

mkdir /tmp/repro && cd /tmp/repro
git init && git commit --allow-empty -m init
git checkout -b feature && git commit --allow-empty -m change

# /security-review  ->
#   fatal: ambiguous argument 'origin/HEAD...': unknown revision or path not in the working tree.

# and the documented workaround also fails, since there's no remote to query:
git remote set-head origin -a
#   fatal: 'origin' does not appear to be a git repository
#   fatal: Could not read from remote repository.

Workaround that does cover the no-remote case

origin/HEAD is just revision syntax — it resolves from a local ref and never
touches the network. So you can create it by hand:

# repo with NO remote at all:
git symbolic-ref refs/remotes/origin/HEAD refs/heads/main

# repo WITH a remote, but origin/HEAD unset and offline:
git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main

Use symbolic-ref, not update-ref — update-ref copies the SHA and silently
goes stale as soon as the base branch advances.

Suggested fix

Fall back when origin/HEAD doesn't resolve, rather than aborting:

git rev-parse --verify --quiet refs/remotes/origin/HEAD >/dev/null \
  && BASE=origin/HEAD \
  || BASE=$(git rev-parse --verify --quiet main >/dev/null && echo main || echo master)

Or use git merge-base against the detected default branch. Even just catching
the failure and emitting "origin/HEAD is not set — run git remote set-head origin -a, or if this repo has no remote, git symbolic-ref refs/remotes/origin/HEAD refs/heads/main" would resolve the original ask here.

Affected

Local-only repos (git init, never pushed) — the common case
Forks/clones where the remote isn't named origin
Clones where origin/HEAD was never set (e.g. git clone -b <branch>)

lujover-afk · 2 days ago

Confirming this is still reproducible. On my setup, origin/HEAD resolves correctly in the actual repo (git rev-parse origin/HEAD succeeds, git branch -r shows origin/HEAD -> origin/master), yet /security-review still fails with the same fatal: ambiguous argument 'origin/HEAD...' error on multiple retries, across different git subcommands (git log --no-decorate origin/HEAD..., git diff --name-only origin/HEAD..., git diff --merge-base origin/HEAD). This suggests the command's pattern-substitution step runs against a different/isolated working copy than the one the user is actually in, where origin/HEAD was never set (e.g. via a shallow or partial clone) — matching the root cause already described here. The proposed fallback (auto-detect via origin/main/origin/master when origin/HEAD is unset) would fix this regardless of which working copy the check actually runs against.

Environment: Windows 11, Claude Code CLI.