1. Classify the failure before removing anything

  • Provider failure: authentication, endpoint, protocol, model ID, rate-limit, or network errors.
  • Workspace failure: path, permission, repository, or sandbox errors tied to one workspace.
  • Profile failure: the Web Profile does not start or several independent capabilities fail together.
  • Plugin failure: the issue begins after one Bundle change and follows that mounted capability.
This controlled connection error is a provider failure, not evidence of a Plugin failure. Classifying the surface prevents unnecessary removals.Harness 0.1.0-rc.7 · macOS 26.4 · Node.js 24.19 · isolated Web Profile · Captured 2026-08-20 · official source

2. Preserve evidence and stop the Profile

Record the exact command, Harness version, Profile, package version, first error, and last known-good action. Stop the process normally before changing Profile files or package state.

# Stop the foreground Web Profile
Control-C

# Confirm the installed Plugin inventory
dsh plugin --profile web list

3. Isolate the suspected Plugin

Search the Plugin list for the mounted name and compare it with the package’s Bundle patch. Disable, remove, or revert only the latest suspect. Do not delete the whole Profile while evidence still points to one change.

Filtering the runtime inventory narrows the suspected surface. Package and mounted Plugin names can differ, so compare both with immutable evidence.Harness 0.1.0-rc.7 · macOS 26.4 · Node.js 24.19 · isolated Web Profile · Captured 2026-08-20 · official source

4. Return to a known-good configuration

  • Keep the Harness version unchanged during the first recovery attempt.
  • Use the same workspace and known-good provider so only the suspect changes.
  • If the Profile still cannot start, test a fresh isolated DSH_HOME instead of deleting the original.
  • Read the package’s removal notes for data or external configuration that may remain.
dsh plugin --profile web remove package-name

# Then restart the same pinned Harness baseline
pnpm dlx @deepseek-ai/dsh@0.1.0-rc.7 web
A known-good provider is retained while the Plugin variable is isolated. This keeps the recovery test interpretable.Harness 0.1.0-rc.7 · macOS 26.4 · Node.js 24.19 · isolated Web Profile · Captured 2026-08-20 · official source

5. Prove recovery with the same small task

Repeat the deterministic task used for the baseline. Recovery is demonstrated when the same task succeeds under the known-good model and Profile—not merely when the UI opens.

The controlled task succeeds again after the provider endpoint is restored. This proves the recovery method in the isolated test environment.Harness 0.1.0-rc.7 · macOS 26.4 · Node.js 24.19 · isolated Web Profile · Captured 2026-08-20 · official source

When to report upstream

Report a minimal reproduction only after you can name the Harness version, package version, Profile, operating system, Node.js version, expected result, actual result, and whether a clean Profile reproduces the issue. Remove secrets and private paths from every log and screenshot.

Review Plugin lifecycle evidence →