gitStatus context snapshot reports `Current branch: HEAD` for a repo on a normal branch (phantom detached HEAD)
Summary
The gitStatus block injected into the session context reports Current branch: HEAD for a repository that is sitting on an ordinary branch (develop). It fabricates a detached-HEAD state. Every git-side check performed in the same session, against the same repo, disagrees with it.
Environment
- Claude Code VS Code extension
2.1.228(win32-x64); the same misreport occurred on an earlier build (2026-08-12,2.1.223–2.1.227era) - Windows 11 (10.0.26200)
- Plain single-worktree repo;
.gitis a normal directory; ordinary files refs backend (not reftable) - The editor/session cwd is a subdirectory of the repo root (
<root>vs. session cwd<root>/<subdir>) — flagging this in case it is relevant
Actual vs. expected
Snapshot injected at session start:
Current branch: HEAD
Main branch (you will usually use this for PRs): main
Status:
(clean)
Live checks, same session, same repository:
| command | output |
| --- | --- |
| git branch --show-current | develop |
| git rev-parse --abbrev-ref HEAD | develop |
| git symbolic-ref HEAD | refs/heads/develop |
| cat .git/HEAD | ref: refs/heads/develop |
| git worktree list | single entry, [develop] |
Identical results whether run from the repo root or from the session's subdirectory cwd.
Expected: Current branch: develop.
Worth noting: the other fields of the same snapshot were accurate — the recent-commits list and Status: (clean) both matched reality at that moment. Only the branch line is wrong, so this does not look like a wholesale stale-cache problem.
Frequency
Not a one-off. Grepping this project's local session transcripts (193 files) for the branch line: the gitStatus block appears in only a couple of them, and every occurrence reads HEAD — it has never once shown the real branch name. Two sessions are confirmed by transcript (2026-08-12 and 2026-08-15), both with the repo on develop and no checkout, rebase, or worktree operation in between.
Impact
The model treats the snapshot as ground truth for branch state. Two concrete failures observed in these sessions:
- It told the user "you are in a detached HEAD state" and proposed running
git checkout developbefore committing — i.e. a state-changing fix for a problem that did not exist. - In a project whose contributing rule is "only ever commit to
develop, never tomain", it hesitated to commit at all, because it could not confirm the branch it believed it was on.
This mainly bites workflows that commit directly to a long-lived branch — documentation repos, vaults, single-maintainer or personal projects. In a PR-based workflow the assistant creates a feature branch anyway, so a wrong branch reading is largely invisible; that may be why this has gone unreported.
Workaround: instruct the model to always run git branch --show-current and disregard the snapshot's branch line.
Possibly related
- #68236 — gitStatus reports branch as
.invalidin reftable-backend repos (reads.git/HEADdirectly), closed as not planned. If the same code path is involved here, note that this repo uses the ordinary files backend and its.git/HEADis a well-formed symref, so whatever fallback produces the literal stringHEADis firing for a different reason. - #53278 — Worktree sessions report the wrong branch in the system prompt, closed as stale. No worktrees are involved in this report.