/doctor skill applies CLI-installation assumptions when run in Claude Code Desktop (Windows)

Environment

• Claude Code Desktop on native Windows 11 (not CLI, not WSL2)
• Desktop session engine version, from the session's own persisted transcript ("version" field): 2.1.246 at session start, 2.1.247 later in the same session — i.e. the Desktop engine self-updated mid-session
• A standalone native CLI binary also exists at ~\.local\bin\claude.exe, version 2.1.220, not on PATH, and not what the Desktop session runs
• Observed 2026-08-30

Summary

The bundled /doctor skill encodes CLI-installation assumptions. Run inside Claude Code Desktop — a documented Claude Code interface with its own update path — it produced PATH and update recommendations aimed at a standalone CLI binary the session was not using.

Reproduction

1. Windows 11 machine with Claude Code Desktop installed, plus a standalone native CLI binary at ~\.local\bin\claude.exe that is older than the Desktop engine and not on PATH.
2. In a Desktop session, invoke /doctor.
3. The skill's installation-health check flags claude missing from PATH and proposes a shell-config fix.
4. The skill's version check compares the standalone CLI binary (2.1.220) against the release channel (2.1.251 at the time) and proposes running claude update.

Observed output (from the session):

Check 7 — version. 2.1.220 → 2.1.251. [...] The manual update is: C:\Users\fljoe\.local\bin\claude.exe update Check 0 — PATH. The launcher exists but claude isn't callable from a shell. [...] Add %USERPROFILE%\.local\bin to your user PATH if you want it.

Meanwhile the transcript's own version field shows the Desktop engine at 2.1.246→2.1.247 in that same session — current, and updated by the Desktop app itself. The recommendations target a binary the user never runs, in an interface that manages its own updates.

Related data-model mismatch

The skill's data-source model reads MCP servers and hooks from the settings cascade (~/.claude/settings.json, project settings, .mcp.json). In the Desktop session these were all empty or absent, yet the session had extensive MCP tool activity — the session's own tool inventory identifies those servers as Desktop-provided surfaces (in-app browser pane, Desktop session tools, computer-use). Hook executions (SessionStart:startup, PreToolUse matchers) were likewise recorded in transcripts with no hook configuration in the settings cascade or in ProgramData\ClaudeCode managed-policy paths; the source of those hooks was not identified from disk. Either way, a checklist that treats the settings cascade as the complete inventory reads a normal Desktop session as contradictory.

Suggestion

Have the skill detect the Desktop runtime (or receive runtime context from the harness) and scope its installation, PATH, and version checks to the running interface — or state in the skill that those checks are CLI-scoped so Desktop users can discount them.

Revised from the original report: an earlier claim that an auto-mode recommendation contradicted automode-blocked transcript records has been removed (those records establish the session's mode, not the persistent defaultMode setting), and an unproven usage-counter observation has been removed pending controlled reproduction.

🤖 Generated with Claude Code