dsh injects Windows system proxy (HTTP_PROXY) into restricted child processes, breaking loopback services (modlens -> LM Studio) with 502

[paicat1]

Summary

On Windows, when a system proxy (WinINET, e.g. Clash at `127.0.0.1:7890`) is enabled, dsh (kernel `0.1.2-rc.1`, bundled with Desktop 0.10.3) injects `HTTP_PROXY`/`HTTPS_PROXY` into restricted child processes (pwsh sandbox, external CLIs like the modlens vision engine). Tools that respect `HTTP_PROXY` then route even loopback (`127.0.0.1`) requests through the proxy, which fails with `502 Bad Gateway`. This breaks modlens (LM Studio at `127.0.0.1:1234`), and would affect Ollama, local gateways, etc.

Environment

• Windows, DSH Desktop `0.10.3` (auto-updated 2026-09-04), bundled dsh kernel `0.1.2-rc.1`
• System proxy ON (WinINET `ProxyEnable=1`, `ProxyServer=127.0.0.1:7890`, Clash)
• modlens provider: `baseUrl http://127.0.0.1:1234/v1\` (LM Studio), model `qwen/qwen3.5-9b`
• Previous kernel `0.1.1-rc.2` did NOT exhibit this (same system proxy, same modlens config worked for weeks)

What happens

• `modlens_read_image` / `modlens_screenshot` fail every time:
  `[modlens] image read failed (engine): Error: OpenAI-compatible API error 502:` (repeated in desktop.log since the 0.10.3 / 0.1.2-rc.1 update)
• modlens uses undici `EnvHttpProxyAgent`, which honors `HTTP_PROXY`; the local request to 127.0.0.1:1234 is forwarded to 127.0.0.1:7890 and fails.

Verification

• `HTTP_PROXY=http://127.0.0.1:7890\` / `HTTPS_PROXY` are present in the env of the pwsh sandbox and the modlens CLI child process, but absent from User/Machine environment variables and from the trusted worker runtime (`process.env` has no proxy vars there). So dsh is injecting them after reading the WinINET system proxy.
• Running `modlens analyze -i ` with `HTTP_PROXY` cleared, OR with `NO_PROXY=127.0.0.1,localhost` set while keeping the proxy, succeeds immediately. Engine and config are fine; the injected proxy env is the only cause.

Expected behavior

Loopback / local addresses (`127.0.0.1`, `localhost`, `::1`) should be excluded from proxy injection (standard NO_PROXY semantics), or child-process proxy injection should be opt-in / configurable. Routing loopback traffic through a proxy is invalid.

Workaround (until fixed)

Set user env var `NO_PROXY=127.0.0.1,localhost` and restart the Desktop app. dsh propagates NO_PROXY to children (bootstrap-inherited), and modlens' EnvHttpProxyAgent then bypasses the proxy for loopback.

Log excerpt

```
2026-09-04 08:40:36Z INFO main::service::update::install: Opening desktop installer: ...Deepseek.Harness.Desktop_0.10.3_x64-setup.exe
2026-09-04 09:25:37Z WARN dsh: [modlens] vision provider waiting for upstream
2026-09-04 09:29:59Z WARN dsh: [modlens] image read failed (engine): Error: OpenAI-compatible API error 502:
```

[paicat1]

Correction (my original report mis-attributed the trigger)

The running dsh kernel is actually 0.1.1-rc.2 (global npm install at AppData\Roaming\npm\node_modules\@deepseek-ai\dsh), NOT 0.1.2-rc.1:

• Desktop 0.10.3 Downloaded dsh core dsh-0.1.2-rc.1-33729514615 but immediately logged Suppressing dsh update above recommended version: 0.1.2-rc.1 — the recommended version is 0.1.1-rc.2, so 0.1.2-rc.1 was never activated (it sits unused on disk).
• The running Harness process (pid 22004) starts ...\AppData\Roaming\npm\node_modules\@deepseek-ai\dsh\lib\bin.js --profile web --port 3080, and Desktop's own patch logs reference the same global-npm paths (version 0.1.1-rc.2, untouched since 08/22 for package.json).

Timeline that reframes the trigger:

• 17:25 local: Desktop restarted (Harness pid 22004)
• 17:15–17:25 same session: modlens reads were still succeeding
• 17:28 local: user toggles/captures the FlClash dashboard with system proxy = ON (WinINET ProxyEnable=1, 127.0.0.1:7890)
• 17:29:59: first [modlens] image read failed (engine): 502

So the trigger is the system proxy being switched ON combined with proxy-following in the child-process environment (HTTP_PROXY appears in the pwsh sandbox and modlens CLI child processes, but NOT in the trusted runtime / process.env of the main worker — so injection happens when constructing restricted child-process env). I have not yet pinned down whether that injection lives in the Desktop 0.10.3 shell or in dsh 0.1.1-rc.2's sandbox code (0.1.1-rc.2's sources show no HTTP_PROXY literal, but the behavior is observable). A kernel upgrade is NOT the cause.

The NO_PROXY=127.0.0.1,localhost workaround and the "loopback addresses should never be routed through the system proxy" ask remain valid.