Desktop CI monitoring panel: state cached at session start, no refresh, misleading error sends users down wrong debug path

Symptom

Claude Desktop's CI monitoring panel persistently shows, for a given session:

CI checks unavailable. Check that gh is installed and authenticated.

The panel itself works (verified: a freshly-spawned session on the same repo, with the same setup, shows the CI status correctly). The bug is that session state for the panel is cached at session start: any setup change completed mid-session is not picked up.

The error message points the user at gh, but gh is verifiably fine in every subprocess context. That sends users on a long debug path through gh install, auth, PATH, env vars, UWP sandbox isolation, OAuth tokens, etc. The actual fix is "spawn a new session for this project."

Environment

• OS: Windows 11 Pro
• Claude Desktop: 1.8555.2.0, Windows Store / UWP install at C:\Program Files\WindowsApps\Claude_1.8555.2.0_x64__pzs8sxrjxfjjc\app\Claude.exe
• Claude Code CLI: 2.1.150
• Plan: Claude Max
• gh CLI: 2.92.0 at C:\Program Files\GitHub CLI\gh.exe
• Repo: a private repo I own in a GitHub org I admin (orwell-int/app_owly)
• GitHub account: miludmann

Reproduction

1. Open Claude Desktop. Start a session in a project that doesn't yet have the Claude GitHub App installed.
2. The CI panel shows "CI checks unavailable. Check that gh is installed and authenticated." Expected at this stage.
3. While the session is still open, complete all the setup: install the Claude GitHub App on the repo, run claude setup-token, store CLAUDE_CODE_OAUTH_TOKEN, run /web-setup from a terminal, complete the GitHub OAuth at https://claude.ai/code, etc.
4. Restart Claude Desktop. Resume the same session.
5. Observe: panel still says "CI checks unavailable" indefinitely. Restarting the Desktop app does not help because the session is resumed from cache, not recreated.
6. Spawn a NEW session in the same project. The panel correctly shows CI status.

Setup that was verified (none of which fixes the original session)

1. gh on system PATH (both Machine and User env).
2. gh auth status reports logged in via Windows keyring with full scopes.
3. GH_TOKEN set as a user env var via setx. Verified inherited by Claude's child subprocess; gh auth status from that subprocess reports Logged in to github.com account miludmann (GH_TOKEN).
4. gh pr list -R orwell-int/app_owly from Claude's subprocess returns the open PRs correctly.
5. Claude GitHub App installed on the repo.
6. claude setup-token run; CLAUDE_CODE_OAUTH_TOKEN stored as repo secret; @claude mentions in PRs/issues fire the action and Claude replies successfully.
7. Logged in at https://claude.ai/code. Repo picker shows the repo and its branches.
8. Cloud session spawned at claude.ai/code targeting the repo.
9. Claude GitHub App listed in https://github.com/settings/applications under Authorized GitHub Apps; configuration finalized.
10. Claude Desktop fully restarted multiple times (system tray verified) — does not help because the affected session is resumed from cache.

The actual bug

Two reasonable asks:

1. Detect setup changes mid-session and re-evaluate panel state (poll on a slow timer, react to webhooks already received by the GitHub App, react to a focus event, etc.).

1. At a minimum, fix the error text. The current "Check that gh is installed and authenticated" sends users down a multi-hour debug path through gh configuration when the actual fix is to spawn a new session. Something like: "GitHub integration was not active when this session started. If you've installed the Claude GitHub App or run /web-setup since opening this session, spawn a new session for this project to pick up the change."

The same session-cache-at-start pattern affects custom subagents in .claude/agents/, which is at least documented for that case. The CI panel doesn't document it and produces a misleading error that points users at the wrong subsystem.

Diagnostic data

Happy to provide additional diagnostics on request: logs from %APPDATA%\Claude\logs\, env dumps from Claude's subprocess context, screenshots of the panel state in the original (broken) session vs the freshly-spawned (working) session.