claude-code - 💡(How to fix) Fix [BUG] Claude Desktop 1.8089.1: marketplace migration race makes user-installed skills unreachable via slash-command

Subject

Claude Desktop 1.8089.1: remoteMarketplaceMigration runs before LocalSessionManager initialization, leaving user-installed skills unreachable via slash-command in Cowork chat

Summary

After Claude Desktop auto-updates from 1.7196.x to 1.8089.1 and the user restarts the application, slash-command invocations of user-installed skills (e.g., /my-skill) return Unknown skill /my-skill in Cowork chat — even though the Skills settings UI shows the skill present and enabled, and the on-disk skill manifest lists the skill with enabled: true. The local SkillsPlugin syncs the skills successfully; the failure is in the chat-side slash-command resolver, which appears to have been refactored in 1.8089.1 to consult a remote-marketplace catalog. Two new migration components, remoteMarketplaceMigration and remoteUploadsMigration, fire at startup before LocalSessionManager finishes initializing the user's account/org context; both fail with paths_unavailable err=Error: No active account/org for marketplace operations. Once the migration fails, NativeMarketplaceReader reports Found 0 marketplace(s), and the resolver can no longer find the skills the manifest knows about. Uninstall + reinstall, disable + enable, and full quit + relaunch do not fix it.

Environment

• Claude Desktop 1.8089.1 (auto-updated from 1.7196.3; the prior version did not exhibit the issue).
• macOS 14+ (Darwin 25.x; behavior likely cross-version but verified on one host).
• Feature gates claudeai_cowork_backend_marketplaces=true and cowork_plugin_host_ops=true are both active in the running build (visible in startup logs).
• One or more user-uploaded skills installed prior to the version upgrade, each present at ~/Library/Application Support/Claude/local-agent-mode-sessions/skills-plugin/<orgUUID>/<accountUUID>/skills/<skill-name>/SKILL.md with disable-model-invocation: true in frontmatter (intended for slash-command invocation, not model auto-invocation).

Symptom

In chat:

> /my-skill
Unknown skill `/my-skill`

Skills settings UI: the skill appears, status Enabled, creator type user.

Local manifest at ~/Library/Application Support/Claude/local-agent-mode-sessions/skills-plugin/<orgUUID>/<accountUUID>/manifest.json lists the skill correctly:

{
  "skillId": "skill_<id>",
  "name": "my-skill",
  "creatorType": "user",
  "enabled": true,
  "updatedAt": "<timestamp>"
}

~/Library/Logs/Claude/main.log at app startup shows the race (timestamps within one second of each other; lines abridged):

[remoteMarketplaceMigration] marketplace_migration.invoked
[remoteUploadsMigration]     upload_migration.invoked
[remoteMarketplaceMigration] gate_check gate=claudeai_cowork_backend_marketplaces value=true
[remoteUploadsMigration]     gate_check gate=cowork_plugin_host_ops value=true
[remoteUploadsMigration]     gate_check gate=claudeai_cowork_backend_marketplaces value=true
[remoteMarketplaceMigration] paths_unavailable err=Error: No active account/org for marketplace operations
[remoteUploadsMigration]     paths_unavailable err=Error: No active account/org for marketplace operations
[LocalSessionManager]        Initialization succeeded — accountId=<redacted>, orgId=<redacted>
[LocalAgentModeSessionManager] Initialization succeeded — accountId=<redacted>, orgId=<redacted>
…
[NativeMarketplaceReader]    Listing marketplaces (native)
[NativeMarketplaceReader]    Found 0 marketplace(s)

After this sequence, SkillsPlugin operates normally — it logs Found N enabled skills, Sync complete: N downloaded, 0 removed, etc. The local manifest layer is healthy. The problem is purely that the chat-side slash-command resolver finds zero marketplaces and therefore zero skills to match the typed /my-skill against.

Minimal reproducer

1. On Claude Desktop 1.7196.x (or any prior build where user-installed skills work via slash-command), install a small user skill via the Skills UI (any minimal SKILL.md is fine).
2. Confirm the skill works: typing /my-skill in a Cowork chat invokes the skill.
3. Allow Claude Desktop to auto-update to 1.8089.1 (or trigger the update via Check for Updates if available). The update typically downloads in the background and applies on next quit.
4. Fully quit Claude Desktop (Cmd+Q) and relaunch. Verify the About dialog reports 1.8089.1.
5. In a fresh Cowork chat in the same project / space as before, type /my-skill.
6. Expected: the skill resolves and executes (as it did on the prior version).
7. Actual: Unknown skill /my-skill. Verify in ~/Library/Logs/Claude/main.log that the most recent app-startup log block contains marketplace_migration.paths_unavailable err=Error: No active account/org for marketplace operations immediately before LocalSessionManager Initialization succeeded.

The race is reproducible on every cold start of 1.8089.1; it's not a one-off.

What we've ruled out

1. Local storage corruption. The skill manifest at ~/Library/Application Support/Claude/local-agent-mode-sessions/skills-plugin/<orgUUID>/<accountUUID>/manifest.json is valid JSON, lists the skill with enabled: true, and the skill body at …/skills/<name>/SKILL.md is intact. SkillsPlugin Sync complete: N downloaded, 0 removed, 0 orphans cleaned confirms the local sync layer works.
2. Stale UI state. Disabling and re-enabling the skill in the Skills UI does not restore slash-command resolution. The manifest gets touched but the chat resolver still returns Unknown skill.
3. Stale skill bundle. Uninstalling the skill, re-uploading from the original .zip bundle, and observing Sync complete: 2 downloaded in the logs (fresh skill IDs in manifest) still produces Unknown skill in chat.
4. Partial app restart. Fully quitting Claude Desktop with Cmd+Q and relaunching (which is how the queued 1.8089.1 update applied) does not change behavior. The migration race fires on every cold start.
5. Account/org actually being unavailable. LocalSessionManager Initialization succeeded — accountId=<id>, orgId=<id> lands within the same log second as the migration's paths_unavailable error — the account/org are available; the migration just runs before them. This is consistent with a startup-ordering bug, not a credentials/auth problem.
6. A specific feature-gate value being wrong. Both claudeai_cowork_backend_marketplaces and cowork_plugin_host_ops are reported as value=true; if the resolver-refactor required them, they're active.
7. Anthropic-provided skills are unaffected. The bundled skills (xlsx, pptx, pdf, docx, skill-creator, etc.) continue to work; only user-installed (creatorType: user) skills break. This narrows the resolver bug to the user-skill / marketplace-catalog code path.

Operational impact

• All user-installed skills become unreachable via slash-command in Cowork chat until a fix lands or the user downgrades. Skills that exist purely to provide reusable orientation / wrap-up / project-specific rituals are blocked. The workaround is to paste the SKILL.md body inline as a chat message; it works but loses the slash-command ergonomics that motivated installing skills in the first place.
• Recurs on every cold start of 1.8089.1. Not a one-time migration error that resolves on retry — the failed migration is not retried within the same process, and on every subsequent restart it fails the same way for the same race-condition reason.
• No discoverable user-facing remediation. Users can see the skill in Settings, can install/uninstall/enable/disable, but no UI control restores slash-command resolution. The fix requires either a vendor patch or a downgrade.
• The Skills settings UI is misleading — it indicates the skill is installed and enabled, but the chat surface that should use it can't find it. Users will reasonably conclude the install failed and try to reinstall (does not help) or contact support.

Related observation: prompt queue loss on stuck-conversation recovery

While diagnosing the marketplace migration race above, a separate but adjacent failure mode surfaced in the same Claude Desktop 1.8089.1 build. Reporting it here because it appears in the same operational context and Anthropic may want to triage them together; if mechanistically distinct, please split into a separate report at intake.

Symptom. A Cowork conversation entered a hung Working on it… state — the spinner indicator persisted indefinitely with no response from the model. While the conversation was in this hung state, the input field continued to accept new prompts and visually queued them in the conversation surface (rendered below the spinner). Three prompts were typed in this state over roughly an hour, each appearing queued but with no model response and no error indication.

When the user eventually quit and relaunched Claude Desktop to recover the conversation, the queued prompts were silently discarded: they did not appear in the post-restart conversation history, were not replayed to the model, and produced no acknowledgement or failure indicator. The user only realized the content was lost after the new (working) conversation resumed.

Inferred mechanism. Queued prompts appear to live in renderer-process memory until the backend acknowledges them via the streaming response channel. When the streaming channel hangs or drops without a clean termination, the input layer continues accepting and rendering new prompts but doesn't durably persist them. On conversation recovery (restart, reconnect, or whatever path is taken), there is no replay-from-queue step; the renderer abandons its un-acknowledged queue and reinitializes empty. The user is given no indication that this loss occurred.

Why this matters for the marketplace bug above. The marketplace race causes new conversations created during the broken-elicitation window to be silently degraded (skills unreachable via slash-command); this related observation causes user prompts typed during the degradation to be silently lost on recovery. Together they create a "silent-failure-during-silent-failure" double-blind that's hard for users to diagnose.

Reproducer (best-effort; the underlying SSE hang is non-deterministic to trigger).

1. Have an active Cowork conversation in a state where the streaming response channel hangs — e.g., during a background auto-update that disrupts the renderer's IPC. The conversation shows Working on it… indefinitely.
2. Type a new prompt and send. Observe it appears queued in the conversation UI below the spinner.
3. Type a second prompt. It also queues.
4. Cmd+Q Claude Desktop, then relaunch.
5. Open the same conversation.
6. Expected: queued prompts either (a) replayed to the model on reconnect, or (b) shown with an explicit "failed to send" indicator preserving the user's typed content.
7. Actual: queued prompts are absent from conversation history; no indication of loss; conversation appears as if those prompts were never typed.

Operational impact. Loss of user-typed content with no warning. Affects user trust — particularly painful when the lost prompts captured substantive context (multi-paragraph framings, pasted code, decisions) that the user expected to be preserved. Workaround is purely defensive: when a hang is suspected, copy queued prompts to the clipboard before recovering the conversation. The need for this workaround is not discoverable from the UI.

What we'd like to understand

1. Is the remoteMarketplaceMigration / remoteUploadsMigration startup ordering relative to LocalSessionManager Initialization defined or undefined? The logs suggest the migrations fire ~1 second before the session manager populates accountId / orgId; if this is undefined, a deterministic ordering fix would address the race.
2. When marketplace_migration.paths_unavailable fires, is the migration component supposed to retry once the session manager initializes, or is it intended to be one-shot? If it's expected to retry on a subsequent session-ready event, that event handler may be missing or misconfigured in 1.8089.1.
3. Is the chat-side slash-command resolver in 1.8089.1 intended to fall back to the local skill manifest when no marketplace catalog is available, or is marketplace registration now a hard requirement? If the latter, the fact that NativeMarketplaceReader returns Found 0 marketplace(s) after the migration failure is a single point of failure for all user-skill resolution.
4. Is there a supported workaround until a patch lands — e.g., a CLI command, a settings toggle, or a config file edit that can force the local manifest into the resolver path?
5. Is this issue known to Anthropic, and if so, is there an ETA for a patched build? The reproducibility on cold start (and the diagnostic clarity of the log lines) suggests this should be a quick fix once the ordering is corrected.
6. (Related observation) Is the prompt-queue loss on stuck-conversation recovery considered a known limitation, or an unintended consequence of the recovery mechanism? Would a queued-prompt indicator (e.g., a "Pending — not yet sent" badge on un-acknowledged prompts) be feasible to surface, so users can recognize when content is at risk of loss before initiating recovery?
7. (Related observation) Is there a stable client-side persistence layer for queued-but-unsent prompts that could survive renderer-process restart, or is the current behavior (renderer-memory only) the design intent?

Contact

GitHub issue author (filed via Claude Code /feedback channel because Cowork's network isolation prevents filing from the sandbox where the bug was diagnosed).