DeepSeek Harness 0.2.1 sidebar 405: webRuntime removed

After upgrading to DeepSeek Harness (DSH) 0.2.1, the sidebar is still there, but Markdown preview will not open, the file tree is blank, and git actions do nothing. Every one of those requests returns 405 with an empty body. This is not networking or permissions: the plugin waits for webRuntime, which 0.2.1 removed in favour of webStartup, so it stays pending and none of its routes are mounted.

DeepSeek Harness empty-body 405 is an unmounted route fingerprint

When every API from one plugin returns an empty 405 and its row is pending, the service name is the cause; a single failing endpoint points at a routing mistake instead. Use the shape of the response to separate the cases:

According to the source review in the discussion, app-boot/src/index.ts:1072-1074 does not re-evaluate an entry that is pending, and frontend-static/src/index.ts:122-125 hands an unmatched POST to the static handler, which answers with an empty 405 (#10027). For normal sidebar usage, see the sidebar plugin tutorial.

Find the plugin before repairing anything:

1. Search the plugin list for pending — collect every row and its waiting service; expected: one or more rows name webRuntime.
2. Match the failing APIs to a plugin — compare the broken features with the plugin that provides them; expected: one plugin covers all failing endpoints.
3. Bisect if several plugins are pending — disable one at a time and restart; expected: the 405 set disappears when the right plugin is off.
4. Use community tooling if available — the activation-doctor plugin lists pending rows with their missing services; expected: the same mapping with less manual work.

What 0.2.1 changed in the DSH web service

The public web service was renamed and the trust configuration changed with it; a plugin that migrates only half of that pair stays pending. The chain:

• The old plugin declares inject: ['webRuntime'] — it waits for that service at startup, so the row does not start on a 0.2.1 host.
• 0.2.1 never registers webRuntime — the service never appears, so the wait never ends.
• The entry stays pending — the host logs a warning instead of failing, so startup succeeds and the problem stays quiet.
• ctx.webRuntime.register(...) never runs — no routes are registered.
• A request arrives — no dynamic route matches, and the static fallback returns an empty 405.

The official upgrade guide records the migration (web-listener-trust-config), but it is easy to miss in release notes.

Three DeepSeek Harness recovery paths

Bottom line: upgrade when the author has migrated, rename the service locally when they have not, and disable the plugin when it is not essential.

Repair 1: upgrade to a build that targets webStartup

The cleanest fix is a newer plugin release, provided the author has migrated. In the discussion's example, the sidebar plugin at 0.24.1 still used webRuntime, while 0.28.0 had moved to webStartup:

1. Read the plugin page — check the latest version and whether its changelog mentions webStartup; expected: the release notes confirm the migration.
2. Update from the plugin market — install the newer version and wait for it to finish; expected: the package under the profile is replaced.
3. Restart DSH — relaunch and inspect the plugin state; expected: pending changes to active.
4. Exercise the sidebar — open preview, the file tree, and a git action in turn; expected: no 405 responses.
5. Check for leftovers — if it is still pending, look for a stale version directory under the profile; expected: only one copy of the plugin remains.

Repair 2: rename the service in the local plugin artifact

When no compatible release exists, the built artifact can be patched by hand; the changes are few but they are not durable.

1. Locate the installed package — for example ~/.dsh/profiles/<profile>/node_modules/dsh-better-sidebar; expected: you are editing the artifact the profile actually loads.
2. List every occurrence — open lib/index.js and search for webRuntime; expected: a complete inventory of references.
3. Change the declaration — replace webRuntime inside inject with webStartup; expected: the row can resolve the new service.
4. Change the call sites — replace ctx.webRuntime with ctx.webStartup, checking whether method names also differ; expected: registration code compiles against the new API.
5. Restart and record — verify the plugin is active and the APIs respond, then note the patch; expected: you can reapply it after the next update.

An update overwrites the change, method signatures may differ, and dependency cleanup can remove the edit, so this patch is temporary.

Repair 3: disable the plugin and use an alternative

If the affected plugin is not essential, disabling it removes both the pending row and the 405s immediately.

1. Disable the plugin — find the one still injecting webRuntime and switch it off; expected: the pending row disappears after restart.
2. Restart and confirm — reload DSH and retry the affected endpoints; expected: no more empty 405 responses and other plugins still load.
3. Replace the capability — use a built-in feature or a plugin already compatible with 0.2.1; expected: the workflow continues without the broken package.
4. Re-enable later — turn it back on once the author ships a compatible version; expected: the capability returns without manual patching.

Verify DSH fixes and avoid regressions

Active status is necessary but not sufficient; every API from the plugin must answer normally after a restart. Verify:

1. Check the row — it must read active, not pending; expected: the plugin mounted.
2. Exercise each API — preview, file tree, git status, and save; expected: all respond successfully.
3. Read the status codes — inspect the browser's developer tools; expected: 200 or 204, never an empty 405.
4. Restart twice — reload DSH again; expected: the state is stable and load order does not push it back to pending.
5. Add an unrelated plugin — install something else and restart; expected: the repaired plugin is not displaced.

Avoid these traps:

• Do not treat the 405 as a backend routing bug; inspect plugin state first and save time.
• webRuntime was a public service name, so removing it is a breaking change; check compatibility before upgrading a host.
• Patching node_modules is not a long-term solution, so record the change and ask the author to migrate.
• Trust configuration also changed in 0.2.1; if the service name is fixed but requests still fail with 403 or 401, inspect trustedHosts and do not blame a DSH plugin permission setting for a routing problem.
• Back up the profile before editing, because the same directory holds settings and session data.

DeepSeek Harness webRuntime FAQ

Q: Why does DeepSeek Harness 0.2.1 return empty 405s from the sidebar APIs? A: DeepSeek Harness returns empty 405s because a plugin still injects webRuntime, which 0.2.1 removed in favour of webStartup. The plugin stays pending forever and never registers its routes, so requests fall through to the static handler; upgrade the plugin or change its inject entry.

Q: What is the difference between webRuntime and webStartup in DeepSeek Harness? A: DeepSeek Harness webRuntime and webStartup are both entry points for plugins that expose web services; 0.2.1 deleted webRuntime, kept webStartup, and changed the trust configuration. A plugin that still declares inject: webRuntime waits for a service that never appears, so every route it would have registered is absent.

Q: How do I confirm a DeepSeek Harness 405 comes from a pending plugin, not a wrong route? A: A DeepSeek Harness 405 from a pending plugin comes with a pending (waiting for service: webRuntime) row and an empty body. A routing mistake usually returns 404 or a body with an error; a pending plugin sends every request to the static fallback, so all of its APIs fail together.

Q: Can I rename webRuntime references in a DeepSeek Harness plugin without an update? A: A DeepSeek Harness plugin can be patched by renaming inject and the ctx.webRuntime call sites to webStartup in the built artifact. This is a local patch that the next update will overwrite, so it is a stopgap until a 0.2.1-compatible release exists.