DSH plugin: sec_e_no_credentials schannel TLS error

sec_e_no_credentials (full form schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS) is often read as "missing API credential", but inside the DeepSeek Harness runtime it is really the Windows native TLS backend (schannel) failing to reach the system certificate/credential store, so every HTTPS request fails. Error X → do W: switch the offending command to the OpenSSL backend, for example git -c http.sslBackend=openssl ..., or bypass Git entirely with the npm channel, rather than swapping your API key (source).

The name carrying credentials is misleading — this credentials means the Windows security package's credential handle, not the model service's API credential. A user hit this in the wild: in a sandbox curl https://github.com returned 000 and git push printed this sentence; the network itself was not blocked, a plaintext request worked, and the TCP connection to github.com:443 went through — only the Windows native TLS credential store was unreachable (source). Below: what it means, how to fix it, and how to verify.

What the sec_e_no_credentials error means: schannel is missing, not your API key

SEC_E_NO_CREDENTIALS is the error code the Windows schannel security package throws when it cannot obtain a usable credential handle; it happens at the TLS handshake stage and has nothing to do with the model API credential — in a sandbox that isolates the system credential store, the schannel handshake fails with this error (source). Compare the cases:

Read it in this order:

1. It is a local TLS-backend problem — schannel needs to read the system certificate and credential store; a sandbox isolates that store, so the handshake fails. Expected: the same command with the OpenSSL backend succeeds.
2. It is not the network being blocked — the TCP connection to the target port usually still establishes, and an http:// plaintext request also works. Expected: connecting but failing HTTPS is the signature of a TLS backend.
3. It is a different thing from the model API credential — the code that means a missing API key in DeepSeek Harness is MISSING_CREDENTIAL (source). Expected: a different error string means a completely different direction.

Keep one sentence: the credentials in this name belong to the Windows security package, not to your API key.

A quick discriminator between the two "credential" errors: one is about the handshake, the other about the request. sec_e_no_credentials fails before any HTTP request is sent — the TLS handshake cannot even start — so nothing reaches the provider and no authentication is attempted. MISSING_CREDENTIAL fails after the request is built, when DeepSeek Harness looks for an API key to attach and finds none. If you see the schannel text, swapping keys changes nothing, because no key was ever consulted.

How to fix sec_e_no_credentials: switch to the OpenSSL backend and bypass with npm

There are two fixes: temporarily switch the offending command to the OpenSSL backend, or just use the npm channel that does not go through Git; both bypass schannel and neither touches your API credentials. Run the steps in order:

1. Switch the TLS backend for a single command — Git for Windows ships OpenSSL and a CA bundle, so add the parameter to that command:
   powershell

   git -c http.sslBackend=openssl push -u origin main
   

   Expected: the command completes the TLS handshake and pushes normally (source).
2. Do not write it into the global git config — using -c affects only this invocation, which is safer; writing it globally changes TLS behaviour for every repository. Expected: schannel works fine in an ordinary terminal, with no global change needed.
3. Install the plugin through the npm channel — a plugin supports both a github: direct install and an npm package-name install; when the schannel error hits, prefer the npm-name route and bypass Git:
   bash

   dsh plugin --profile web add <npm package name>
   

   Expected: the install no longer triggers the TLS-backend error (source).
4. Retry in an ordinary terminal — leave the sandbox and run the same operation in a plain terminal. Expected: schannel can reach the credential store normally, usually needing no extra parameters (source).
5. Record and reuse the fix — make "this environment goes OpenSSL backend / goes npm" a habit, to step around the same pitfall in later commands. Expected: similar HTTPS operations no longer throw this sentence.

Why the parameter is scoped to one command: the OpenSSL backend exists for cases like this, but switching it globally changes how every repository negotiates TLS, including ones behind a corporate proxy that expects schannel; keeping it on the single command that runs inside the sandbox leaves the rest of the machine on the default backend. The npm route is even narrower — a plugin install never invokes Git, so no TLS-backend choice is involved at all.

One plugin-related note: if you hit this sentence while installing a plugin, the npm channel is the least trouble; once it is installed, cross-check its source and version in the DSH Plugin Hub installed list.

How to verify it and the common misconfiguration: do not treat it as a missing API key

Verification has two layers: first confirm the relationship between the network and TLS (TCP works, HTTPS fails because of the backend), then retest with the backend-switched command; the most common misconfiguration is treating it as a missing API key and swapping keys over and over — which fixes nothing (source). Run the steps in order:

1. Confirm the network is not blocked — test whether a TCP connection to github.com:443 establishes and whether an http:// plaintext request works. Expected: TCP works and plaintext works, meaning the problem is only the TLS backend.
2. Tell "cannot connect" from "repository does not exist" — Failed to connect or SEC_E_NO_CREDENTIALS is a TLS-backend problem, while remote: Repository not found. means TLS is already through and only the repo is not created. Expected: locate it by the error string, without misjudging.
3. Retest with the backend-switched command — rerun the command with -c http.sslBackend=openssl. Expected: success proves it was schannel's fault and unrelated to credentials.
4. Compare with the real credential error codes — if you suspect a model-credential problem, look for MISSING_CREDENTIAL / UNKNOWN_MODEL, covered in DeepSeek Harness API key errors: MISSING_CREDENTIAL and UNKNOWN_MODEL; for a 401, see DeepSeek Harness "available models" 401. Expected: you can tell "TLS-backend error" apart from "model-credential error" and stop crossing wires.
5. Common misconfiguration checklist:
   • treating it as a missing API key and regenerating / replacing keys over and over — ineffective;
   • writing http.sslBackend=openssl into the global config — too broad an impact, and unnecessary;
   • assuming it is a repository-permission problem — a failed authentication reports authentication failed, not this sentence.

The misjudgment that wastes the most time is blaming the repository. A private repository you genuinely lack access to reports authentication failed or Repository not found, both after a successful handshake; this error reports the handshake itself. If curl to the same host returns 000, the repository question is moot until the TLS backend is fixed.

Troubleshooting notes for a DSH plugin on Windows

1. Read the string before acting — sec_e_no_credentials is a TLS-backend error, not a credential error.
2. Change the backend for a single command only — -c http.sslBackend=openssl is use-and-discard, so do not globalize it.
3. Prefer the npm channel — when installing a plugin, go npm instead of Git and bypass schannel.
4. An ordinary terminal usually needs no change — in a non-sandbox environment, schannel is generally usable.
5. Compare with the real credential code — MISSING_CREDENTIAL is the signal for a missing API key.

The official DSH plugin TLS mechanism under the Windows sandbox

At the official-mechanism level, two points are enough: the sandbox isolates the Windows TLS credential store; and a plugin's network requests therefore often run explicitly in an unrestricted mode to avoid being held up by the ACL sandbox. Two points:

1. What is isolated is the credential store, not the network — under the sandbox schannel cannot get a credential, but TCP and plaintext requests work (source). Expected: rule out "the network is blocked" first when judging the problem.
2. Plugins adjust their run mode to step around the restriction — some plugins make requests run explicitly in an unrestricted way on Windows, because a sandboxed PowerShell cannot complete a schannel handshake (source). Expected: with this layer understood, the same class of error reads as an environment limit rather than a plugin defect.

Rather than treating this environment error as a credential problem and swapping keys over and over, use the DSH Plugin Hub install confirmation dialog to add the plugins you need — seeing what command it runs before install saves more trouble than debugging afterwards. Its home page is https://dsh-plugin.org/.

Sources: deepseek-ai/deepseek-harness (official repo), DeepSeek API official docs, community plugin dsh-computer-use-mode.