gitStatus context snapshot reports `Current branch: HEAD` for a repo on a normal branch (phantom detached HEAD)

Status Open
Reported on v2.1.228
Maintainer reply None cached
Activity 0 comments · opened Aug 15, 2026

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.2232.1.227 era)
  • Windows 11 (10.0.26200)
  • Plain single-worktree repo; .git is 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 develop before 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 to main", 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 .invalid in reftable-backend repos (reads .git/HEAD directly), closed as not planned. If the same code path is involved here, note that this repo uses the ordinary files backend and its .git/HEAD is a well-formed symref, so whatever fallback produces the literal string HEAD is 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.

View original on GitHub ↗