Repository navigation
[Known issue]: Desktop plugin upgrade can leave account controls unavailable until cold restart #371
Description
DSH baseline
Official Windows Desktop 0.2.0-rc.2.
Plugin release or commit
Observed after an in-place upgrade from 0.4.0-alpha.80 to 0.4.0-alpha.130. The Desktop process started before installation completed; installed-on-disk version did not prove loaded Host/Client version.
Affected surface
Known issue: post-install/upgrade runtime activation; Models account status and management controls.
Repository preflight (optional)
Read-only repository preflight passed. No live credentials or settings dumps collected.
Minimal reproduction
- Install or upgrade the plugin while Desktop remains running.
- Before a full cold restart, open Settings > Models > GitHub Copilot > Manage.
- In the reported incident, status showed
Status unavailable/Could not check account status, account metadata could not be read, and account actions were unavailable.
This is an observed incident, not a claim that every upgrade reproduces it. Credential expiry or revocation was not established.
Expected behavior
Installation/upgrade should either activate consistent Host/Client services or clearly communicate the required restart without leaving an apparently deadlocked account interface. No proven plugin-only seamless hot-reload solution is currently accepted.
Actual behavior
The account interface appeared unusable until a full Desktop restart. The reporter confirmed that restarting restored normal account management. This resolves the immediate incident, not the underlying upgrade experience.
Known workaround: fully quit Desktop, including its tray/background process, then launch it again. Closing the window to the tray is not a cold restart. Do not delete credentials, sign out, repeatedly reinstall, or weaken account identity/activity/CAS safeguards merely to address this post-upgrade symptom.
Prior research and limits: rc.2 lifecycle characterization documents staged service-composition limitations and missing public rebinding/dispatch seams. That synthetic Web lifecycle evidence is related context, not proof of the exact internal cause of this account-status incident or a full native package-manager test. Native restart-required upgrade behavior is a separate boundary. No Core patches, dependency edits, private registry changes, or automatic restart are authorized by this issue.
Tracking status: keep open as a known issue at the user's request. The experimental account-recovery changes were withdrawn; no fix was shipped for this incident. Revisit when supported public lifecycle APIs or a verified plugin-local approach can improve activation/restart guidance without weakening safety or disrupting running work.
Safety checks
- I removed credentials, tokens, OAuth grants, and raw sensitive provider responses.
- This is not a security vulnerability requiring private disclosure.
Activity
cloga commentedon Oct 6, 2026
The reporter confirmed that a full Desktop restart after plugin installation restored normal account management. The observed incident was post-upgrade runtime activation, not established credential expiry. The local recovery-action experiment has been withdrawn without publication; existing identity, activity, and mutation safeguards are unchanged. Closing this incident as resolved by restart. A future recovery UX change requires its own verified scope.
[-][Bug]: Preserve account recovery actions when status or identity reads fail[/-][+][Known issue]: Desktop plugin upgrade can leave account controls unavailable until cold restart[/+]cloga commentedon Oct 24, 2026
Current supported-core reassessment: the plugin pins DSH
0.2.1-rc.3, so I reran the public Loader/Web characterization against those exact packages. The synthetic fixture now verifies that a single-step hot add preserves active search and fetch consumers, but staged add strands the globalwebservice, and cold-load → remove → re-add leaves it unavailable with the consumer pending. Calling the publicctx.reflect.notify(['web'])after re-add does not recreate that service. This is a reproducible plugin-composition hot-readd defect; the plugin's account integration is nested behindctx.inject(..., 'web', ...), which can block dependent Host account services. The fixture does not establish that this was the sole internal cause of the reported incident.The exact rc.3 public
WebRuntimesurface still has provider registration plussearch()/fetch()and volatile selection config, but no selected-provider dispatch middleware or service-replacement/rebinding contract. Additive registration cannot retain configured-provider semantics and the plugin's primary/fallback routing. A supported repair needs either disposable middleware on the existing runtime after normal provider selection, or a Loader-owned operation that restores the service and rebinds dependents after isolation changes. A public dependency notification alone is insufficient, so I made no speculative runtime changes. The native plugin-manager rc.3 test separately confirms an in-place upgrade without HMR isrestart-requiredand leaves the current runtime version active; honor that manager contract rather than promising a seamless upgrade. Quota request CA handling is unrelated to this lifecycle.Focused fixture: 5 tests passed. Full
pnpm verify: 2,775 Vitest passed, 2 existing skips; 391 tooling tests passed; types, build, baseline and package smoke passed. The issue remains open; the branch contains only characterization and guidance updates, not a fix.docs: characterize rc.3 Web hot-readd limitation (#440)
cloga commentedon Oct 24, 2026
Reopening as explicitly required by this investigation: #440 was merged as documentation and regression evidence only, not a runtime fix. The issue closed at merge time, but the hot-readd Web-service defect remains reproduced on official DSH 0.2.1-rc.3. Delivery CI and existing-version GitHub/npm reconciliation passed in run 40138372904; no new runtime version or repair was shipped. Remaining blocker: a supported public Web dispatch middleware with native delegation and exact-provider routing, or Loader-owned restoration/rebinding of the global Web service after isolation transitions. Live Desktop and accounts remain untouched.
cloga commentedon Oct 24, 2026
Current review incorporates merged #440 (
552de4c), not a duplicate repair. Exact rc.3 characterization distinguishes working one-step hot add from staged add/remove-readd that can strand the publicwebservice; public notify does not restore it, and native non-HMR upgrade reports restart-required.Decision: retain as a confirmed native lifecycle limitation. The merged documentation/tests correctly characterize it but do not fix or close it. No existing public atomic dispatch/rebind seam has been established for a plugin-only hot-readd repair. Private registries/prototypes, replacing Core, or restarting the user's running Sessions are not acceptable workarounds in this task.
Retirement trigger: qualify an unchanged official Core whose public lifecycle resolves the staged sequence, then run the existing characterization plus real activation acceptance. Until then, documented cold restart remains a separately authorized operational step, not an automatic action.
cloga commentedon Oct 25, 2026
PR #453 now carries the version-neutral lifecycle guidance and has been refreshed from main at edca08c. The branch prepares (but does not publish) same-Core alpha.4 metadata so the release-ready gate can pass; the rc.3 release line remains pending. Exact-head CI run 40186259720 is running. This is a copy/metadata PR, not a runtime repair; the issue remains open and no install/restart or release was performed.
cloga commentedon Oct 25, 2026
Update for PR #453: refreshed the branch onto current main 6c36189 and prepared
Remove stale Core version from lifecycle note (#453)