Which profile gets your dsh plugin: web, desktop, custom

A dsh plugin lands in the profile that launched it, and that single fact explains most install confusion. DeepSeek Harness keeps separate plugin sets for the browser, the desktop client and any custom launch you define. The package is the same everywhere, while the profile decides where it appears.

How profiles decide where a dsh plugin lands

A profile is a named set of plugins and settings, and the launcher selects one before any plugin loads.

The browser entry starts the web profile, and the desktop client starts its own. A custom profile exists because someone passed an explicit name at launch. In each case the active profile is chosen before the plugin list is read.

Installation writes to the active profile unless you name another one. That default is convenient and easy to forget, especially when two windows are open. Check the active profile before concluding that an install failed.

The same package can exist in several profiles as independent copies. Each copy has its own version and settings, so updating one does not update the others. Treat every profile as a separate deployment target.

This separation protects a stable daily setup from experiments. It also means the phrase installed but missing usually describes a target problem rather than a broken package. Once you accept that, diagnosis gets much shorter.

Installing a dsh plugin into the web profile

The web profile serves the browser interface, so browser-only work belongs there.

Start the browser entry and confirm which profile it reports. Then install with the profile flag rather than relying on the default. Listing the plugins in that profile is the fastest way to confirm the write landed.

Refresh the page after installing, because the market view can cache its list. If the plugin appears in the list but not in the interface, check whether it needs enabling. A reload resolves most of these cases.

dsh plugin install @scope/my-plugin --profile web
dsh plugin list --profile web

Record the version you installed next to the profile name. When the web and desktop copies drift, that note tells you which one you meant to update. It also makes rollback a lookup instead of a guess.

The DSH Plugin Hub entry is a reasonable place to confirm package names before installing. Copy the name from there rather than retyping it from memory. Small spelling differences produce install failures that look like compatibility problems.

Installing a dsh plugin into the desktop profile

The desktop profile is a separate target and sometimes needs an extra apply or restart step.

Confirm the desktop client version supports the plugin before you start. Some plugins rely on capabilities that arrive later than the browser equivalent. A version mismatch here looks like a broken install.

Install with the desktop profile named explicitly, then restart the client so the plugin loads. If the client offers an apply step, run it before testing. Watching the plugin list after restart is more reliable than watching the interface.

Keep a note of the desktop version separately from the web version. The two profiles can run different builds of the same plugin, and that is allowed. What is not allowed is assuming they stay in sync.

Desktop releases can lag behind the browser, so a plugin that works beautifully in one place may not exist in the other. Check the changelog before promising a feature on both. The profile is doing its job when the difference is visible rather than surprising.

Why a custom dsh plugin profile is worth the trouble

A custom profile is a disposable boundary for testing one change at a time.

Create it with a name that states its purpose, such as a plugin under evaluation. Install only what the test needs, because a crowded profile hides the effect you are looking for. Delete it when the question is answered.

Do not promote a custom profile into your daily setup by copying the directory. Old paths and stale state travel with it, and the copy inherits problems you meant to leave behind. Reinstall from the manifest instead.

A custom profile also gives you a safe place to test a changelog upgrade before it touches the browser. That is the cheapest rollback plan available, and it costs one directory. Use it whenever a release note mentions loading or storage.

The name of the profile is documentation for future you. A name like test is useless a month later, while a name like hub-upgrade-check tells the whole story. Spend the extra second.

Diagnosing a dsh plugin installed in the wrong profile

Wrong-target symptoms are consistent: the market shows the plugin, while the active profile does not.

First confirm the entry point you are using and the profile it launched. Then list the plugins in that profile and compare the result with what the market shows. The difference between those two lists is the whole diagnosis.

If the plugin is missing from the list, it went somewhere else or the install failed. If it is present in the list but absent from the interface, the problem is loading rather than targeting. Those two cases need different fixes.

1. Confirm the entry point and active profile.
2. List plugins in that profile.
3. Compare with the market listing.
4. Check the install log for the profile name.
5. Reinstall into the correct profile if needed.
6. Restart or reload the entry.
7. Verify by using the plugin, not by reading the list.

A wrong target is cheaper to fix than a broken package, because nothing needs rebuilding. The fix is usually one install command with the right flag. The expensive part is the time spent blaming the author.

Moving a dsh plugin between DeepSeek Harness profiles

Migration is a reinstall with intent, not a directory copy.

Export the manifest from the source profile and install those DSH plugins into the target. Copy configuration selectively, then check every path and credential reference. A wholesale copy carries assumptions that no longer hold.

Test the target profile with a real task before deleting the source. A DeepSeek Harness plugin that loads can still fail when it reaches for a path from the old profile. The task is the only proof that matters.

Then write down the mapping: which plugin belongs to which profile and why. That note prevents the same confusion the next time someone opens the wrong window. Profiles are cheap to create and expensive to reason about without a record.