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

[jaimegago]

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.

[jaimegago]

Environment

• Claude desktop app: 1.10628.2
• Platform: macOS (Darwin 25.4.0)
• Surface: FleetView session header (desktop app)

[legend84800-jpg]

+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]

Also an issue on Windows fyi

[aurja130]

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

[joergwachner]

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/) 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.