DeepSeek Harness REQUEST_EXTENSION Troubleshooting

When DeepSeek Harness reports DeepSeek request extension preparation failed with the REQUEST_EXTENSION code, the model API may never have received the request. DSH runs request extensions before each model call to add fields such as the active plugin inventory. On older versions, one failing extension can terminate the turn before the HTTP request begins.

That makes the error easy to misdiagnose as an invalid API key, exhausted credit, network failure, or unavailable model. A better order is to establish whether the failure happened during local request preparation, inspect recent plugin and Profile changes, and only then investigate the Provider.

Identify a request-extension failure

Common signs include:

• every message fails immediately, sometimes together with automatic session-title generation;
• the interface shows DeepSeek request extension preparation failed;
• the error code is REQUEST_EXTENSION;
• DeepSeek is affected while another Provider may still work;
• a direct call with the same API key succeeds, but DSH fails almost immediately;
• logs contain no Provider request ID, HTTP status, or rate-limit response.

The last two are diagnostic clues rather than absolute rules. If the log contains 401, 402, 429, or a Provider request ID, follow the credential, credit, or rate-limit path instead of changing plugins.

Where the request stops

A model call can be simplified as:

user message
  → read Session and model configuration
  → prepare request extensions
  → merge extension fields
  → send the HTTP request to the Provider
  → consume the streaming response

plugin-package-inventory-deepseek is a frequent source of this error family. It inspects active Loader entries and represents identifiable packages in dsh_plugin_packages. A model does not need this inventory to understand the user's message, but the older preparation path treated the extensions as one unit: failure to resolve any active entry rejected preparation and prevented the HTTP request.

For that reason, “only DeepSeek fails” does not prove that the DeepSeek API is down. The DeepSeek adapter may simply be the path that enabled this specific request extension.

Four common causes

1. A stale entry remains after uninstall

A marketplace or manual installation mounted a Bundle into the Profile, but uninstall left an empty directory, stale state record, or unresolvable Loader entry. DSH still sees an active item while the inventory extension cannot locate its package.

This often begins after an install-disable-uninstall-restart sequence. Inspect the current Profile's installed Bundles and active Plugins through the Plugins interface or Plugin Manager. Do not start by deleting the entire Profile or node_modules tree.

2. A local-file plugin has no complete package identity

A Profile can reference a local .ts, .js, or .mjs file or a directory, while the inventory extension still needs to map that active item to a package identity. Resolution can fail when the nearest package.json has a name but no non-empty version, or when no usable manifest exists.

Place a local plugin in its own directory and provide at least:

{
  "name": "my-dsh-plugin",
  "version": "0.1.0"
}

This version identifies the local package; it does not publish the plugin to npm.

3. Windows junctions or fallback links are broken

On Windows with a pnpm workspace, junctions, relative symlinks, and the Profile module-fallback directory can form an invalid resolution path. The plugin can exist and may even be active in the Loader, while the inventory resolver searches from another anchor and reports cannot resolve active package.

If the failure begins after an upgrade, names an official @deepseek-ai/dsh-* package, and does not change after the API key is saved again, inspect installation and Profile package resolution before rotating credentials.

4. The Profile Patch still enables old configuration

The plugin file moved or disappeared while its cordis.patch.yml row remained enabled, or the recorded package name and directory no longer match the installation. A successful DSH boot does not guarantee that every active entry can be resolved again during request preparation.

Identify the most recent row first and disable it through the Plugins interface. If manual recovery is required, back up the Profile and disable only the target entry instead of commenting out or deleting unrelated sections.

Recommended troubleshooting order

1. Record the version and complete error

Capture the DSH package or bundled Desktop version, active Profile, operating system, and the presence of REQUEST_EXTENSION. “The turn failed” alone is insufficient because other failure codes belong to different call paths.

2. Determine whether the Provider received a request

Check elapsed time, HTTP status, Provider request ID, and server-side usage. Failure within milliseconds with no Provider record usually points to local preparation. If a service status exists, follow that response instead.

3. Review recent plugin changes

Work backward through:

1. a newly installed or updated third-party Bundle;
2. a recently removed entry that still appears in the Profile;
3. a local file or directory plugin;
4. a migrated Profile;
5. module links left by an upgrade on Windows.

Disable one suspected entry at a time and retest. This both proves the cause and avoids removing working plugins.

4. Validate the manifest

For local or third-party plugins, inspect the nearest package.json. name and version should be non-empty strings, the entry file should exist, and the Profile's recorded name should match the installed package.

5. Recover instead of rebuilding everything

Prefer Plugin Manager operations that disable, remove, or reinstall the identified Bundle. Deleting all of ~/.dsh, a Profile, or node_modules destroys useful diagnostic state and can affect Sessions and unrelated plugins.

Temporary recovery on older versions

After confirming that plugin-package-inventory-deepseek is the failing component on a version with the old fail-closed behavior, temporarily disabling that extension can restore model calls. Requests no longer carry the dsh_plugin_packages field, while the basic model call can proceed.

This isolates the failure; it does not repair the configuration. Follow up by removing the stale entry, completing the manifest, or restoring package resolution. An extension that enforces security, permissions, or required context should not be treated as optional in the same way.

What changed in v0.2.1-alpha.2

Earlier versions could abort an entire model call when one request extension threw. v0.2.1-alpha.2 changes that handling: it records an attributable warning, allows the request to continue, and suppresses repeated diagnostic floods.

The change prevents a broken plugin inventory from automatically making every conversation unusable. It does not repair every corrupt plugin state. A warning still means the configuration is incomplete, and degraded execution is unsafe when the missing extension supplies permissions, security policy, or task-critical context.

npm latest and next currently remain on 0.2.0-rc.2, so ordinary installs do not receive alpha.2 automatically. Pin the full version and back up Profiles and Sessions when testing the new behavior:

npx @deepseek-ai/[email protected] web

Quick diagnosis table

Related reading

• DeepSeek Harness v0.2.1-alpha.2 update
• DeepSeek Harness Plugin Manager
• DeepSeek Harness security model
• Complete DeepSeek Harness setup and usage guide

References

• Chat requests fail with REQUEST_EXTENSION when a plugin package is broken
• Local file plugins make DeepSeek requests fail with REQUEST_EXTENSION
• Windows profile module fallback resolution failure
• REQUEST_EXTENSION durable error details discussion
• v0.2.1-alpha.1 to v0.2.1-alpha.2 official source comparison
• @deepseek-ai/dsh npm versions