[Bug][Windows Desktop 0.2.0-rc.2] Generic transport failure persists across reinstall/reset due to Node CA, stale state, and Electron UI cache

[shinji00222]

Summary

On Windows Desktop 0.2.0-rc.2, DeepSeek Messages transport failed can become very hard to recover from in a normal proxy / TLS-inspection environment.

The same DeepSeek API key and deepseek-flash request work outside the desktop app, but the desktop UI may still keep failing until all of these are handled together:

1. stale per-session model selections under %USERPROFILE%\.dsh;
2. the Electron/Node host process not trusting the OS certificate store unless launched with NODE_OPTIONS=--use-system-ca;
3. the already-running Electron single-instance process keeping the old environment;
4. Electron UI state under %APPDATA%\@deepseek-ai\dsh-desktop, which is not reset by reinstalling the app or moving %USERPROFILE%\.dsh.

This makes the visible error look like a generic model transport failure, while the real cause is hidden in the desktop host / runtime state.

Environment

• OS: Windows 11 25H2 (CurrentBuild=26200)
• DeepSeek Harness Desktop: 0.2.0-rc.2
• Installed path: default per-user Windows install
• Network environment:
  • local proxy env vars existed (HTTP_PROXY / HTTPS_PROXY / ALL_PROXY -> local proxy port)
  • NO_PROXY was configured for localhost, 127.0.0.1, ::1, deepseek.com, .deepseek.com, api.deepseek.com
  • TLS inspection / proxy-style certificate chain was suspected from prior SELF_SIGNED_CERT_IN_CHAIN reproduction

What I observed

The desktop UI repeatedly showed:

DeepSeek Messages transport failed

Reinstalling the desktop app did not fix it, because the failing state survived in user data.

After a clean %USERPROFILE%\.dsh reset, the app still did not fully recover until the desktop UI data directory was also reset.

Checks that passed

The key and provider were not the root issue:

• GET https://api.deepseek.com/models with the configured key returned 200.
• A minimal deepseek-flash chat completion with the same key returned 200.
• Fresh sessions used:

{
  "provider": "deepseek-official",
  "model": "deepseek-flash",
  "reasoningEffort": "high"
}

• Local desktop host was listening on 127.0.0.1:19387.
• Searching the fresh %USERPROFILE%\.dsh showed no stale deepseek-v4-pro / deepseek-v4-flash strings.

Recovery steps that were required

The desktop app only became recoverable after doing all of the following:

1. Back up and move %USERPROFILE%\.dsh.
2. Let the app generate a fresh %USERPROFILE%\.dsh.
3. Restore / configure the API key.
4. Add a desktop profile patch for the default model:

- id: agent-default-model
  name: "@deepseek-ai/dsh-agent-default-model"
  config:
    provider: deepseek-official
    model: deepseek-flash
    reasoningEffort: high

5. Launch the app with:

$env:NODE_OPTIONS = "--use-system-ca"
$env:NO_PROXY = "localhost,127.0.0.1,::1,deepseek.com,.deepseek.com,api.deepseek.com"

6. Before launching, force-close all existing DeepSeek Harness.exe processes. Otherwise Electron single-instance behavior can reuse the old process and the new environment does not take effect.
7. Back up and move the Electron UI data directory:

%APPDATA%\@deepseek-ai\dsh-desktop

After that directory was regenerated, the desktop app started again with a fresh UI state.

Why this feels like a product bug

I understand that the local machine has a proxy / TLS-inspection environment, so a Node CA issue is plausible. But the desktop app currently makes the failure much harder to diagnose than it needs to be:

• The UI only reports DeepSeek Messages transport failed.
• It does not expose the underlying cause such as SELF_SIGNED_CERT_IN_CHAIN, proxy failure, stale model selection, or host process reuse.
• Reinstalling the app does not reset either %USERPROFILE%\.dsh or %APPDATA%\@deepseek-ai\dsh-desktop.
• Resetting %USERPROFILE%\.dsh alone still leaves Electron UI/local-storage state behind.
• Launching again may reuse an existing Electron single-instance process, so environment fixes like NODE_OPTIONS=--use-system-ca may not apply.

Suggested improvements

• Detect SELF_SIGNED_CERT_IN_CHAIN / certificate validation failures and show an actionable message in the UI.
• Consider launching the bundled Node host with OS trust store support on Windows, or provide a documented desktop setting for it.
• Add a "Reset desktop state" / "safe mode" option that clearly resets both:
  • %USERPROFILE%\.dsh
  • %APPDATA%\@deepseek-ai\dsh-desktop
• When the user changes settings or relaunches after a transport failure, ensure the host process is restarted instead of silently reusing an old process environment.
• Include the original transport cause in the UI or diagnostic export, not only the generic DeepSeek Messages transport failed.

I can provide more sanitized diagnostics if needed, but I intentionally omitted API keys and full personal paths here.

[shinji00222]

中文\n\n更新：我现在确认 DSH 已恢复可用。Windows 上通过稳定启动入口让 Electron/Node 使用系统 CA 后，新会话可以正常收到回复；之前的 Node 直连请求在未启用该选项时出现 SELF_SIGNED_CERT_IN_CHAIN，启用后 API 和模型请求返回成功。\n\n建议 Windows 桌面版在启动 host 时自动启用 Node 系统 CA（--use-system-ca），并保留已有的 NODE_OPTIONS；同时确保重启时旧的单实例进程退出，避免新环境变量没有进入实际处理请求的进程。若仍失败，详细诊断信息最好能显示脱敏后的底层传输错误，方便区分证书、代理和会话状态问题。\n\n## English\n\nUpdate: I can confirm DSH is working again. On Windows, launching Electron/Node with the system CA enabled through a stable launcher allowed fresh sessions to receive replies. Previously, Node requests failed with SELF_SIGNED_CERT_IN_CHAIN without this option; with it enabled, the API and model requests succeeded.\n\nSuggested Windows desktop fix: enable Node’s system CA (--use-system-ca) when starting the host while preserving existing NODE_OPTIONS. Also ensure any old single-instance process exits on restart so the new environment reaches the process handling requests. If failures persist, detailed diagnostics should expose a sanitized underlying transport error to distinguish certificate, proxy, and session-state issues.