DSH Plugin market not updating: cache, refresh timing

The DSH Plugin market is not a live view of a database; it is a composite of a remote index, a local cache and whatever your client knows how to render. That is why a package can be published on npm while the market still looks empty, and why clearing the npm cache changes nothing. Before treating the catalog as broken, decide which of those three layers is actually stale.

Why the DSH plugin market is a snapshot, not a feed

The DSH plugin market renders an index it does not own, so every listing is a copy made at some earlier moment.

The remote catalog is maintained outside your machine and supplies names, versions, descriptions and update times. The client reads that catalog and displays it; it does not watch npm or receive a push when something new appears. A catalog entry is therefore a record about a package, not the package itself, and the two can move at different speeds. Nothing in the interface tells you the age of the copy you are looking at.

A local index cache exists so the page opens quickly instead of waiting for a network round trip. When that cache is stale, entries that were removed can linger and entries added after the last fetch never appear. The resulting screen looks old rather than broken, which is why people reach for a refresh before checking anything else. The cache is a performance feature, but it is also the most common source of "the market is missing a plugin".

The client version decides how much of the catalog can be rendered. An older client may ignore fields or categories it does not recognize, and a plugin can be present in the index while its entry is silently incomplete. That failure looks like a missing plugin from the outside, even though the remedy is an upgrade rather than a cache clear.

Which DSH plugin market entries change, and why timing varies

Entries change for a small number of reasons, and none of them comes with a promised delay.

• New listing: the entry moves from absent to present.
• Version update: the version number and the timestamp change.
• Delisting or withdrawal: the entry may disappear or stay frozen.

Each event travels through the same index and cache path, so each one can appear late for a different reason. Treating all three as "the market is slow" hides which record you are actually waiting for.

Index refresh runs on the market side, and delivery to your client adds another layer of caching. No public schedule guarantees that a package published at one minute will be listed at the next, so any claim of a fixed delay is unreliable. A DeepSeek Harness plugin can be perfectly installable from npm while its market entry is still absent. The honest expectation is a lag with unknown length, not a countdown.

The two systems also fail independently. A publish can succeed while indexing skips an entry, and an index can update while your local copy stays behind. When you need to know whether the plugin exists, ask npm first and treat the market as a discovery layer that may catch up later.

Reading stale DSH plugin market data correctly

The symptom is more useful than the clock: each kind of staleness points at a different layer.

If the page will not load at all, the problem sits below the catalog and belongs to the network. If old entries remain while new ones are absent, the local index cache is the first suspect. If the same account and network shows the plugin on another machine, compare client versions before touching any cache.

A search mismatch can imitate a stale catalog, because the market does not match every field the same way. Trying the package name, the author or a shorter keyword costs less than clearing anything and often ends the investigation. Only when a known package is absent under several search terms does the index deserve attention.

What a DSH plugin market refresh really does

Refresh, restart and cache clearing act on different stores, and the npm cache is not one of them.

1. Page refresh: re-renders data the client already holds, which makes it the cheapest first action but not a real update.
2. Client restart: re-initializes the process and fetches the catalog again, which resolves most stale-cache cases.
3. Index-cache clear: worth trying only when you suspect corruption, and its location varies by version and deployment.

The npm cache is a separate store for downloaded packages. Cleaning it affects future installs and downloads, but it cannot add, remove or update a catalog entry. Reinstalling the client is the last resort, because it costs you profiles and sign-in state without guaranteeing a fresher index.

Keeping notes after each action is more valuable than the action itself. If a restart changed the listing and a cache clear did not, you have learned which layer was stale and can skip the rest next time. That record also makes a useful issue report if the catalog stays wrong across machines.

Cross-checking a DSH plugin market entry with the CLI

Command-line facts answer what exists and what is installed without the interface in between.

npm view <package> version confirms that the package resolves and which version is current. dsh plugin list shows the DSH plugins installed in the current profile, with their versions. Comparing the two tells you whether you are missing an entry, missing an install or looking at a rendering limit.

A package that exists and is listed but not installed points to the install step rather than the catalog. A package that exists while the market stays silent points to the index or to the client that reads it. Installed DSH plugins are a profile fact, so never use that list as evidence of what the catalog offers.

Save the output of all three checks before changing anything, because the comparison is the diagnosis. Repeating the same commands on another machine localizes the difference in one pass. When the results agree everywhere, the catalog is probably fine and the original search term was the problem.

Sources: DSH Plugin Hub entry, DeepSeek Harness quickstart, npm @deepseek-ai/dsh.