[Windows][Standalone 0.2.2-rc.2] Enabled plugin is reported as unavailable: live bundle resolver says not found although package resolves from both expected anchors

[apuhuang-vesync]

Summary

On a Windows machine running standalone DeepSeek Harness 0.2.2-rc.2, the Plugins page reports the enabled dsh-codex-subscription plugin as not running / package unavailable, with the diagnostic cannot resolve profile bundle. Its ChatGPT subscription model group consequently does not appear in the model selector.

The web app itself is healthy and usable. The issue appears confined to plugin bundle resolution/loading. This is a standalone Harness launched through a compatibility launcher, not the regular Electron Desktop installation.

Environment

• OS: Windows (exact build not collected)
• Harness: standalone 0.2.2-rc.2
• Plugin: dsh-codex-subscription@3.2.11
• Profile: web

Observed state

• The DSH web service is running and the UI loads.
• The Plugins page renders the subscription plugin as enabled but not running / unavailable.
• The displayed Host diagnostic is cannot resolve profile bundle.
• The ChatGPT subscription model group is absent while that bundle is unavailable.
• The profile dependency declaration, bundle registration, lock metadata, installed package metadata, and bundle patch file are present.
• The credential store and model-catalog cache files are present. Their contents were not read or shared; authentication status is therefore not asserted here.
• No reinstall, reauthorization, profile rewrite, or credential change was performed during this investigation.

Diagnostic comparison

The read-only live plugin-manager bundle listing reports the plugin as installed and enabled, but with availability=missing and an underlying bundle-resolution-not-found category. The call takes about 14 seconds. A separate model-catalog RPC succeeds in about 28 ms, so the delay/failure is specific to plugin management rather than the general web service.

The installed 0.2.2-rc.2 resolver implementation checks an installation package anchor and then the selected profile's package.json anchor. A read-only invocation of that same resolver against both expected anchors on disk successfully resolves dsh-codex-subscription@3.2.11 and finds its bundle metadata. Thus the observed on-disk package resolves outside the running Host, while the live Host reports it missing.

This currently points to an unresolved difference in the live Host's actual installation anchor, profile directory/context, or filesystem view. The available read-only plugin-manager API does not expose those resolver inputs, so the cause is not yet established. A stale cached result is possible but unconfirmed.

Questions for maintainers

1. Is there a supported way to inspect the active Host's actual installAnchor, selected profile directory, and per-anchor bundle resolution result without exposing sensitive paths?
2. Can the plugin manager return a structured resolver failure that identifies which anchor was checked and why resolution failed, while redacting local paths?
3. Are there known differences between plugin-manager inventory resolution and the profile-boot resolver in 0.2.2-rc.2?
4. Could a read-only diagnostic/preflight expose a mismatch between the profile's dependency, lock/package installation, and bundle registration without mutating them?

Related reports

• Discussion #1377 describes a dependency/package/lock inconsistency that can leave a bundle unresolvable after plugin install reconciliation. Its disk state differs from this report.
• Discussion #5483, #913, and #6539 cover stale or dangling profile bundle references. They do not establish the cause here.
• The 0.2.2-rc.2 release notes mention improved visibility for enabled plugins that fail to load. That may explain why the failure is now clearly surfaced; it does not by itself show that rc.2 introduced the underlying resolution problem.

I can provide additional redacted, allow-listed diagnostic output if maintainers can identify a safe read-only probe. I will not post profile files, raw logs, authentication URLs, OAuth/token data, or personal filesystem paths.

[PerryLink]

Both use the same resolver; the anchors are what differ.

resolveBundleDir is packages/boot/app-boot/src/profile.ts:651-663: it tries packageDirFromAnchor(installAnchor, name) and then join(profileDir, 'package.json'), and throws the exact message you quoted at :659. The plugin manager's detail path calls the same function (packages/boot/plugin-manager/src/bundle-detail.ts:40) with options.profile.installAnchor and options.profile.dir, so there is no second resolver whose behavior could differ — either the anchors passed differ, or the live process resolves from a different filesystem view.

installAnchor is documented as "absolute path of a file inside the dsh app package (its package.json)" (:645-650). Your compatibility launcher is the first suspect: if it starts the app through a shim, the anchor may point at the shim's package rather than the app's.

On your other questions: the message names the profile directory but not the anchor, and no structured per-anchor result exists today. A read-only probe that calls resolveBundleDir once per anchor and prints which one returned is two lines — that is the diagnostic to ask for, not a new API.

I read the source only; no launcher reproduction here.

Hand this to an AI assistant to build that two-anchor probe from your launcher's paths.

If this answers it, marking it as the answer helps the next person with the same panel message.

[apuhuang-vesync]

Thanks, that clarified the resolver path. I tested the two anchors using paths derived from the active standalone launcher. The launcher starts Node directly with the active @deepseek-ai/dsh CLI and sets DSH_HOME; it does not invoke an npm bin shim. In rc.2, INSTALL_ANCHOR is derived from ../package.json relative to profile-boot. I isolated the calls to the exported resolveBundleDir: the app package anchor alone does not resolve dsh-codex-subscription, while the web profile anchor resolves version 3.2.11. The live plugin manager still reports the bundle as installed but unavailable; its read API does not expose the running profile's installAnchor or dir. So the launcher source does not appear to be using a shim, but this probe does not reveal the actual in-memory profile object. Is there a supported read-only way to inspect those runtime values or a redacted per-anchor diagnostic? I have not restarted DSH or changed profile/plugin/credential data.

[apuhuang-vesync]

Update (2026-11-13): I continued testing after the install task reported dsh-codex-subscription@3.2.14. Enabling the plugin led to an account-status read timeout twice. I then used “Clear login information” and signed in again in the browser. After that, the account showed as authenticated, quota data loaded, the ChatGPT subscription model group appeared, and a model conversation completed successfully. The plugin is now usable on my setup.

One discrepancy remains: the plugin UI shows 3.2.14, while the selected web profile's dependency, installed package manifest, and lock metadata still report 3.2.11 with pre-install timestamps. I have not established whether the installer actually updated that profile, so I cannot attribute the original bundle-resolution failure solely to stale login state.