Session diff chip (+X -Y / "Commit changes") shows cumulative session changes, not uncommitted changes

Status Closed — duplicate
Maintainer reply None cached
Activity 2 comments · opened Jul 31, 2026 · closed Aug 15, 2026

Description

The status bar chip in the Claude Code app (desktop/remote UI) shows a diff
counter next to a "Commit changes" button, e.g. stage.msp stage-cf +74 -27 [Commit changes].

The number is the cumulative diff of everything the session has changed
(session-start HEAD → current HEAD), not the working-tree state. It does not
reset when commits are made through git in the session's own shell.

Reproduction

  1. Have Claude edit a file, then commit it via a Bash git commit (not the UI button).
  2. Repeat over several small commits (my case: 4 commits, +74/-27 total).
  3. git status is clean, git diff is empty — but the chip still shows +74 -27

next to an active "Commit changes" button.

Expected

Either the counter tracks uncommitted changes (matching what a "Commit changes"
button implies), or the UI distinguishes "committed this session" from
"uncommitted" — e.g. 4 commits · +0 -0 uncommitted.

Actual

The chip reads as "there are +74 -27 uncommitted changes waiting to be
committed," which sent us checking git status/git diff --cached for
changes that didn't exist. The button offers to commit when there is nothing
to commit.

Why it matters

For workflows where the model commits step-by-step with reviewed messages
(fix-per-commit), the chip is actively misleading: it grows monotonically while
the tree stays clean. The session-cumulative number is useful information — it
just shouldn't wear a "Commit changes" label.

Verified by exact match: git diff <session-start>..HEAD --stat = +74 -27,
while git diff and git diff --cached were both empty.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗