sec_e_no_credentials 报错怎么解决？DeepSeek Harness schannel TLS 排查

sec_e_no_credentials（完整形态 schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS）常被当成「缺 API 凭证」，但在 DeepSeek Harness 的运行环境里，它其实是 Windows 原生 TLS 后端（schannel）取不到系统证书/凭据存储，导致 HTTPS 请求全部失败。对应动作是「对那条命令改用 OpenSSL 后端，例如 git -c http.sslBackend=openssl ...，或用 npm 通道绕开 Git」，而不是去换 API key（来源）。

名字里带 credentials 很容易误导——这里的 credentials 指 Windows 安全包的凭据句柄，不是模型服务的 API 凭证。有用户实跑遇到：在沙箱里 curl https://github.com 返回 000，git push 报这句；但网络本身没被封，明文请求正常、到 github.com:443 的 TCP 连接也通，只有 Windows 原生 TLS 的凭据存储不可达（来源）。下面讲清含义、修法与验证。

sec_e_no_credentials 报错含义：schannel 缺的不是 API 凭证

SEC_E_NO_CREDENTIALS 是 Windows schannel 安全包在取不到可用凭据句柄时抛的错误码，它发生在 TLS 握手阶段，与模型 API 凭证毫无关系；在隔离了系统凭据存储的沙箱里，schannel 握手会以这个错误失败（来源）。 对照着看：

按顺序认一遍：

1. 它是本机 TLS 后端的问题：schannel 需要读系统证书与凭据存储；沙箱隔离了这块存储，握手就失败。预期：换成 OpenSSL 后端的同一命令能成功。
2. 它不是网络被封：到目标端口的 TCP 连接通常仍然可建立，http:// 明文请求也正常。预期：能连上但 HTTPS 失败，是 TLS 后端的特征。
3. 它和模型 API 凭证是两回事：DeepSeek Harness 里代表缺 API key 的是 MISSING_CREDENTIAL（来源）。预期：报错串不同，处理方向完全不同。

记住一句话：这个名字里的 credentials 是 Windows 安全包的，不是你的 API key。

一个快速判别两个「凭证」错误的办法：一个关乎握手，一个关乎请求。 sec_e_no_credentials 在任何 HTTP 请求发出之前就失败了——TLS 握手都起不来，所以没有任何东西到达提供方、也没做认证尝试。MISSING_CREDENTIAL 则在请求构造完成之后失败：DeepSeek Harness 去找要附上的 API key 却找不到。看到 schannel 那句话时，换 key 什么都没变，因为根本没有任何 key 被用到。

sec_e_no_credentials 怎么修：改用 OpenSSL 后端与 npm 绕开

修法有两条：对触发报错的那条命令临时切换到 OpenSSL 后端，或干脆改用不经过 Git 的 npm 通道；两者都绕开 schannel，不需要碰 API 凭证。 按顺序执行：

1. 对单条命令切换 TLS 后端：Git for Windows 自带 OpenSSL 与 CA 证书包，给那条命令加参数即可：
   powershell

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

   预期：命令能完成 TLS 握手、正常推送（来源）。
2. 不要写进全局 git 配置：用 -c 只对当次调用生效更安全；写进全局配置会影响所有仓库的 TLS 行为。预期：普通终端里 schannel 能正常工作，无需全局改动。
3. 改用 npm 通道安装插件：插件既支持 github: 直装也支持 npm 包名安装；遇到 schannel 报错时优先用 npm 包名方式，绕开 Git：
   bash

   dsh plugin --profile web add <npm 包名>
   

   预期：安装不再触发 TLS 后端错误（来源）。
4. 在普通终端里重试：离开沙箱、在普通终端里执行同样的操作。预期：schannel 可正常访问凭据存储，通常不需要额外参数（来源）。
5. 记录并复用修法：把「该环境走 OpenSSL 后端 / 走 npm」固化成习惯，后续同类命令少踩坑。预期：同类 HTTPS 操作不再报这句。

为什么这个参数只绑一条命令：OpenSSL 后端正是为这类情况准备的，但全局切换会改变每个仓库的 TLS 协商方式，包括那些依赖 schannel 的公司代理仓库；把它留在沙箱里跑的那一条命令上，机器其余部分仍走默认后端。npm 通道更窄——插件安装根本不调用 Git，也就完全不涉及 TLS 后端的选择。

补一句和插件相关的：如果是在安装插件时撞上这句，改用 npm 通道安装最省事；插件装好后可以在 DSH Plugin Hub 的已安装列表里核对来源与版本。

怎么验证与常见误配：别把它当成缺 API key

验证分两层：先确认网络与 TLS 的关系（TCP 通、HTTPS 是因为后端失败），再用切换后端的命令复测；最常见的误配就是把它当成缺 API key 去反复换 key——换多少都不管用（来源）。 按顺序执行：

1. 确认网络没被封：测试到 github.com:443 的 TCP 连接是否可建立、http:// 明文请求是否正常。预期：TCP 通、明文通，说明问题只在 TLS 后端。
2. 区分「连不上」与「仓库不存在」：报 Failed to connect 或 SEC_E_NO_CREDENTIALS 是 TLS 后端问题；报 remote: Repository not found. 说明 TLS 已通、只是仓库还没建。预期：按报错串定位，不误判。
3. 用切换后端的命令复测：重跑带 -c http.sslBackend=openssl 的命令。预期：成功即证明是 schannel 的锅，与凭证无关。
4. 对照真正的凭证错误码：如果你怀疑是模型凭证问题，看的是 MISSING_CREDENTIAL / UNKNOWN_MODEL，处理见《DeepSeek Harness 配置 API Key 报错：MISSING_CREDENTIAL 与 UNKNOWN_MODEL》；若报 401，见《DeepSeek Harness 报「获取可用模型」401》。预期：分清「TLS 后端错」与「模型凭证错」，不再串线。
5. 常见误配清单：
   • 把它当成缺 API key，反复生成/替换 key —— 无效；
   • 把 http.sslBackend=openssl 写进全局配置 —— 影响面过大，不必要；
   • 以为是仓库权限问题 —— 认证失败会报 authentication failed，不是这句。

最浪费时间的误判是去怪仓库。 一个你确实没有权限的私有仓库，报的是 authentication failed 或 Repository not found，两者都在握手成功「之后」；这个错报的是握手本身。如果 curl 到同一台主机返回 000，在 TLS 后端修好之前，仓库的问题根本无从谈起。

DSH插件 排查注意事项

1. 先认串再动手：sec_e_no_credentials 是 TLS 后端错，不是凭证错。
2. 只对单条命令改后端：-c http.sslBackend=openssl 用完即弃，别全局化。
3. 优先 npm 通道：安装插件时能走 npm 就不走 Git，绕开 schannel。
4. 普通终端通常无需改动：非沙箱环境里 schannel 一般可用。
5. 对照真凭证码：MISSING_CREDENTIAL 才是缺 API key 的信号。

DSH插件 在 Windows 沙箱下的 TLS 机制

官方机制层面，理解三点就够：沙箱会隔离 Windows 的 TLS 凭据存储；插件的网络请求因此常常显式在不受限模式下运行，避免被 ACL 沙箱卡住；沙箱限制的是凭据存储而非网络栈。 三点说明：

1. 隔离的是凭据存储，不是网络：沙箱下 schannel 取不到凭据，但 TCP 与明文请求正常（来源）。预期：判断问题时先排除「网络被封」。
2. 插件为绕开限制会调整运行方式：有插件在 Windows 上让请求显式以不受限方式运行，因为沙箱化的 PowerShell 无法完成 schannel 握手（来源）。预期：理解这层后，遇到同类报错知道是环境限制而非插件缺陷。
3. 沙箱隔离的是 ACL 与命名空间，不是网络栈：schannel 依赖的凭据存储与证书库在沙箱里不可达，而 TCP/UDP 仍然通，所以同一环境里「DNS 能解析、TCP 能连、HTTPS 握手失败」这三件事可以同时成立（来源）。预期：遇到「连得上但握手不了」，先想到沙箱对凭据存储的隔离，而不是 DNS 或防火墙。

与其把这类环境报错当成凭证问题反复换 key，不如顺手用 DSH Plugin Hub 的安装确认弹窗装需要的插件——装之前先看清它跑什么命令，比事后排查省心。

来源：deepseek-ai/deepseek-harness（官方仓库）、DeepSeek API 官方文档、社区插件 dsh-computer-use-mode。