[FEATURE] No visibility into which Claude Code CLI version Desktop has pinned, or how stale it is vs. current npm/GitHub releases (distinct from #71784, #46541, #75355)

Problem Statement

Claude Desktop (macOS) bundles its own copy of the Claude Code CLI under ~/Library/Application Support/Claude/claude-code/<version>/, fetched by an internal component (logged as [CCD]) from https://downloads.claude.ai/claude-code-releases/<version>/darwin-arm64/claude.app.tar.zst.

Traced through ~/Library/Logs/Claude/main*.log on my machine, this bundled CLI version is pinned at Desktop-build-cut time, not fetched fresh at update time. Every [CCD] Installed bundle download fires within 1-2 seconds of a Desktop app relaunch after an update, and the CLI version only changes when the Desktop team's release happens to reference a different pinned CLI version — not on every Desktop update:

2026-07-21 21:36:23  Starting app { appVersion: '1.24012.1' }   → CCD installs 2.1.217 (21:36:25)
2026-07-25 02:29:12  Starting app { appVersion: '1.24012.9' }   → CCD installs 2.1.219 (02:29:13)
2026-08-03 20:10:34  Starting app { appVersion: '1.24012.11' }  → (no new CCD download — same CLI pin as .9)
2026-08-05 01:04:29  Starting app { appVersion: '1.25927.0' }   → CCD installs 2.1.221 (01:04:30)
2026-08-07 08:22:53  Starting app { appVersion: '1.26832.0' }   → CCD installs 2.1.222 (08:22:54)

Meanwhile the CLI itself ships to npm roughly once a day (2.1.221 Aug 3, 2.1.222 Aug 4, 2.1.223 Aug 5, 2.1.224 Aug 7 01:36 UTC). So the CLI version bundled into any given Desktop release is already behind npm/GitHub's CHANGELOG.md by the time that Desktop release ships, and stays behind until the Desktop team cuts a build with an updated pin — independent of how often the user relaunches Desktop, and independent of the CLI's own release cadence.

None of this is visible anywhere in the product. Desktop shows an "Update available / Relaunch to update" banner for its own app version, which reasonably reads as "you're now current." There's no indication that relaunching pulls a CLI version that was pinned whenever that Desktop build happened to be cut, nor any way to see the gap between the bundled CLI and what's actually current upstream, short of grepping local logs and diffing timestamps against the public CHANGELOG (which is how this was found).

Proposed Solution

Surface the pinned CLI version and its staleness somewhere a user can actually see it, e.g.:

• Show the bundled CLI version (and ideally "N versions/days behind current") in Desktop's About/Settings panel, alongside the Desktop app version.
• Or: have claude --version / /status inside a Desktop-hosted session note when it's running a Desktop-pinned bundle rather than an independently-updating install, so users don't assume claude update semantics apply.
• At minimum, document (in the changelog or a Desktop-specific doc) that the bundled CLI is pinned per-Desktop-release rather than continuously synced, so users don't reasonably assume "relaunch to update" implies "now running the latest CLI."

Alternative Solutions

Currently the only way to check is manual: grep ~/Library/Logs/Claude/main*.log for [CCD] Installed bundle, compare the version against CHANGELOG.md on GitHub, and infer the pin behavior from correlating Desktop relaunch timestamps against CCD download timestamps. Not something a typical user would do or should have to do.

Priority

Medium - would be very helpful

Feature Category

Other

Use Case Example

1. User sees Desktop's "Relaunch to update" banner and relaunches, reasonably assuming this brings them current on everything, including the embedded CLI.
2. A CLI-only security or correctness fix ships to npm the same week.
3. User has no way to know the fix isn't in their Desktop-bundled CLI yet, because nothing in the UI distinguishes "Desktop app is current" from "bundled CLI is current" — these are apparently different pins on different release cadences.
4. The only way to notice the gap is to independently track the CLI's own changelog and compare version numbers by hand.

Additional Context

This mechanism appears to be specific to Desktop's macOS CLI bundling (the [CCD] component) and is distinct from the native installer's own auto-update path and from claude update/claude doctor, which check a different channel. Happy to share the full log excerpts used to trace this if useful for reproduction.

Not a duplicate of existing open/closed requests

Checked against the existing update-notification issues before filing — none of these cover the pinned-bundle mechanism above:

• #71784 (open) — asks for an attention icon on the existing "Relaunch to update" banner. That banner is about Desktop's own app version; this report is about the fact that relaunching for that banner does not imply the bundled CLI is current, and there's no separate signal for the CLI's staleness at all, icon or otherwise.
• #46541 (closed) — requested a session-start notification for the native installer's update path (~/.local/share/claude/versions/). Different mechanism entirely — no Desktop app or [CCD] component involved.
• #75355 (open, Linux) — about the Linux auto-updater pruning binaries still in use by running sessions, causing fragmentation, plus a general "no update notification" complaint. Different platform, different root cause (a pruning race, not a version-pin/staleness-visibility gap), and not about the Desktop-bundled CLI specifically.

This report is specifically: Desktop pins a CLI version at build-cut time (confirmed via [CCD] Installed bundle log correlation with Desktop relaunch timestamps, see table above), that pin is invisible in the UI, and there's no way to tell how far it lags the CLI's own npm/GitHub release train short of manually diffing logs against the public changelog.