[BUG] Desktop "Add marketplace" reports "Failed to add marketplace" while the sync is still in progress and subsequently succeeds

Environment

• Claude Desktop 1.30096.5, macOS (Darwin 24.1.0)
• Account-scoped marketplace add via the desktop Plugins UI
• Public GitHub marketplace repo: DocketDrafter/docketdrafter-plugins

What we observed

We hit this on two consecutive days, with the marketplace repo in two very different shapes.
All timestamps below are from main.log / claude.ai-web.log on the same machine.

Incident 1 — 2026-08-15. Marketplace repo was ~176 MB packed (plugins bundled large
static content).

• 12:34:16 — addMarketplaceViaRemote / createAccountMarketplace issued.
• ~30 seconds later — the client RPC failed with

[remoteMarketplaceClient] transport error: This operation was aborted; the UI showed
"Failed to add marketplace."

• 12:35:36 — retried the add. The backend responded:

MARKETPLACE_ERROR: REMOTE_SYNC_PENDING — already_connected, prior sync still in progress
(status: in_progress) — i.e., the "failed" add had registered the marketplace and its sync
was still running server-side.

• A later retry showed the marketplace connected and syncing, and it became usable.

Incident 2 — 2026-08-16. We had restructured by then: the marketplace repo itself is now
~855 KB (catalog only), and its seven plugin entries are sha-pinned
git-subdir sources referencing a separate content repo (~177 MB packed).

• 15:29:59 — add attempt; at 15:30:29 the client logged

transport error: This operation was aborted and the UI showed
"Failed to add marketplace."

• 15:31:04 and 15:31:44 — further attempts from the UI.
• The third attempt succeeded and the marketplace has worked normally since.

One more data point: a test marketplace with a single git-subdir entry referencing a
~15 MB content repo synced in ~2.4 seconds through the same account-scoped flow
(pollSyncUntilDone ... settled after 2438ms in our logs) — so small syncs complete well
inside the client's patience.

Our reading

The client appears to give the add RPC roughly 30 seconds (observed twice), while the
backend treats the sync as a longer-running job that continues after the RPC is gone — the
backend's own REMOTE_SYNC_PENDING / already_connected / status: in_progress response in
incident 1 says as much. When the sync outlives the RPC, the UI reports failure for an
operation that is still succeeding.

Incident 2 suggests the sync duration tracks the total content behind the marketplace rather
than the marketplace repo itself: shrinking the repo from 176 MB to 855 KB did not change the
user-visible outcome once the plugin entries referenced the same content externally, while
the single-small-entry test synced in ~2.4s. That is consistent with sync/validation fetching
referenced plugin sources, though we can't see the backend to confirm.

Why it matters

Our marketplace ships bundled state-statute corpora for offline legal research
(~100–200 MB per plugin), and our users are attorneys, not developers. The first thing a new
customer does is add the marketplace — and the first thing they may see is a false "Failed."
Unlike developers, they don't retry; they conclude the product is broken. We've added a
"wait a minute and try again" note to our README, but first-touch UX is the one place we
can't paper over a misleading error.

Suggested improvements

Smallest first — any one of these would resolve the customer-facing problem:

1. Reflect the async job in the UI. The backend already tracks status: in_progress and

reports already_connected on re-add. Polling that state and showing
"Adding marketplace — still syncing…" would replace a false failure with the truth.

1. Honest copy if the timeout stays. "Still syncing — check back in a minute" instead of

"Failed to add marketplace."

1. Cheaper sync where possible. If sync/validation primarily needs plugin manifests, a

partial (--filter=blob:none) fetch could avoid transferring full content at add time.

1. Consider archive sources for account-scoped marketplaces (currently rejected with

marketplace_sync_external_source_unsupported; the CLI supports them). A sha256-pinned
archive under the documented 256 MiB cap gives the sync a bounded, verifiable unit to
validate, if manifest checking is the goal.

Repro

Our public marketplace reproduces this as-is:

1. Desktop app → Plugins UI → add https://github.com/DocketDrafter/docketdrafter-plugins

(an ~855 KB catalog whose seven plugin entries are sha-pinned git-subdir sources into
DocketDrafter/docketdrafter-plugin-content, ~177 MB packed).

1. Observe "Failed to add marketplace" at ~30 seconds.
2. Wait a minute or two, retry, and observe that the marketplace connects and works.