Claude Code on Claude Desktop app (mac os): FleetView header shows "Commit changes" button + diff counter on a clean working tree

Status Open
Maintainer reply None cached
Activity 6 comments · opened Jun 4, 2026

The per-repo session header displays a diff counter (e.g. +12,543 −3,695) next to a "Commit changes" button. The counter reflects the branch's diff against the base branch (git diff main...HEAD), but the button label implies there is uncommitted work pending.

This is misleading: immediately after committing and pushing — when git status reports a completely clean working tree — the counter stays populated and the button remains active, suggesting there is still something to commit when there is not.

Repro

  1. On a feature branch with commits ahead of main, commit and push all changes (clean working tree).
  2. Observe the header still shows a large insertion/deletion count and an active "Commit changes" button.
  3. git status confirms nothing to commit.

Expected

The counter and button should distinguish committed branch changes vs. base from uncommitted working-tree changes. With a clean tree, the "Commit changes" button should be disabled/hidden (or relabeled, e.g. "Branch diff: …"), so it does not imply pending work.

View original on GitHub ↗

5 Comments

jaimegago · 2 months ago

Environment

  • Claude desktop app: 1.10628.2
  • Platform: macOS (Darwin 25.4.0)
  • Surface: FleetView session header (desktop app)
legend84800-jpg · 1 month ago

+1, hitting this too. Beyond the stale counter bug described here, it would help to have a Preferences toggle to hide this FleetView session header entirely (branch name, diff counter, Commit/Create PR button). There is currently no setting anywhere to turn it off, and it stays on screen for every session regardless of the working tree state.

jrxpana · 1 month ago

Also an issue on Windows fyi

aurja130 · 1 month ago

Same issue on Debian when running the beta release of the Claude desktop app for Linux.

joergwachner · 1 month ago

On the Claude Code desktop app (Windows 11, model Opus 4.8), the footer diff counter compares the working branch against main and produces a number reflecting the branch's entire multi-year history rather than any actionable change set.

In my repository:

The counter shows +429,861 / −58,567.
This reconciles exactly to a three-dot diff against origin/main:
$ git diff origin/main...Dev --shortstat
3119 files changed, 429633 insertions(+), 58567 deletions(-)
The deletions match the UI to the digit; the ~230 extra insertions are my uncommitted working-tree changes.

Root cause is the comparison base. origin/main's merge-base with my working branch is from 2023-09-27 (~3 years ago), and origin/main itself hasn't moved since 2025-02-24. So the three-dot diff is essentially the whole history of the working branch since it forked, and long-untouched files appear as +N −0 because they didn't exist at the fork point.
In our workflow main is effectively abandoned — the working branch is the trunk and is never merged back into main. Comparing against main therefore yields a number that is technically correct but meaningless day-to-day, and it never responds to actual edits.

Request: base the diff on the current branch's upstream (@{u}, e.g. origin/<branch>) instead of a hardcoded/default main, or make the base branch configurable. For teams whose real trunk differs from the app's assumed main, the counter is otherwise unusable.

Environment: Windows 11, Claude Code desktop app, Opus 4.8; Git host: Azure DevOps.

Showing cached comments. Read the full discussion on GitHub ↗