DeepSeek Harness behind Zscaler: loopback and CA setup

"My laptop happily runs cc, codex, and copilot CLI, but dsh is the only one that fails" — that sentence is itself the clue: the internet is not down, the local loopback path is being intercepted by the proxy. Zscaler opens a local listening port to take over traffic, and DSH also starts its own random local port for client-to-host communication (#10439). Identify the environment first, then configure layer by layer.

DeepSeek Harness: Step 1: three signals that this is a corporate network issue

When all three hold, treat it as a corporate proxy problem and stop looking at installation or permissions.

1. The machine runs a security gateway client such as Zscaler, and it has a local listening port.
2. Local loopback communication is intercepted: use curl http://127.0.0.1:<local-port>/ and see whether it is redirected or blocked.
3. The symptom is "the external part works but the local link does not", not every request timing out.

Two supporting signs: sibling CLIs work while DSH does not, and everything works once the proxy software is disabled. The first points at a path difference, the second at proxy interception.

DSH plugin: Step 2: let local communication bypass the proxy

Exclude localhost, 127.0.0.1, and ::1 from the proxy first; this comes before any other proxy configuration.

1. In the system proxy or PAC, set those three hosts to direct.
2. Write localhost,127.0.0.1,::1 explicitly into NO_PROXY.
3. Keep the existing intranet entries and join everything with commas.
4. Do not use semicolons — one semicolon invalidates the entire exclusion list.
5. Also do not write wildcards like 10.*.*.*; they do not work. Intranet ranges need concrete hostnames or domains.

After this step, the desktop app should at least start and connect to its own host, and only external requests remain.

DeepSeek Harness: Step 3: make external requests actually use the proxy

Node's built-in fetch does not read proxy variables by default, so you must enable it explicitly or setting HTTPS_PROXY does nothing.

1. Confirm Node is 22.21+ or 24.x; older versions lack this switch.
2. Set HTTP_PROXY and HTTPS_PROXY, plus ALL_PROXY if needed.
3. Set NODE_USE_ENV_PROXY=1.
4. Verify against an external address: getting a response means the proxy chain works.
5. Return to DSH, send a message, and confirm external requests are fine.

DSH Plugin: Step 4: trust the corporate CA

A SELF_SIGNED_CERT_IN_CHAIN error means the company performs HTTPS inspection and the corporate root certificate must be added to the trust chain.

1. Ask IT for the corporate root certificate PEM file.
2. Set NODE_EXTRA_CA_CERTS=<certificate path> using an absolute path.
3. Restart the app and try again.
4. Do not use NODE_TLS_REJECT_UNAUTHORIZED=0; that disables all certificate verification.
5. If a certificate rotation brings the error back, replace the certificate first before suspecting other config.

DeepSeek Harness: A ready-to-use environment variable list

This is the set the community reporter ended up with; substitute your own proxy address and certificate path.

$proxy = "http://127.0.0.1:9000"
$env:HTTP_PROXY  = $proxy
$env:HTTPS_PROXY = $proxy
$env:ALL_PROXY   = $proxy
$env:NO_PROXY    = "localhost,127.0.0.1,::1"
$env:NODE_USE_ENV_PROXY = "1"
$env:NODE_EXTRA_CA_CERTS = $caBundle

A few reminders: replace the proxy address with the real listening port on your machine; if NO_PROXY needs intranet hosts, append them after a comma, never a semicolon; and $caBundle must be the absolute path to the PEM.

DSH plugin: Why the desktop app needs user-level variables

Launched from the icon, the desktop app does not inherit variables you set temporarily in a terminal, so writing them there is the same as not writing them.

1. Set the variables as user-level environment variables in system settings.
2. Fully quit the app, including the tray icon and any leftover process in Task Manager.
3. Start it again and re-verify both the local and external paths.
4. If it still fails, launch the app binary from a terminal as a control — if that works, the problem is variable scope.

A verification order: local, external, then app

Verify one layer at a time so a failure points at a specific configuration item.

1. Local: curl http://127.0.0.1:<host-port>/ should return directly rather than being redirected.
2. External: curl https://api.deepseek.com/ should return a normal response, not a certificate error.
3. App: start DSH and send a message, confirming there are no proxy-related errors.
4. If any layer fails, go back to that step and fix it alone; do not change several variables at once.

Cautions

Change one network layer per test so a failure points at one setting.

1. Do not work around it by disabling Zscaler. It is corporate security policy; bypassing it is neither practical nor compliant.
2. Do not configure only the external proxy. When loopback is intercepted, a working external proxy does not help.
3. Do not separate NO_PROXY entries with semicolons. One semicolon breaks the whole exclusion list.
4. Do not use wildcards for intranet ranges. Write concrete domains or hostnames.
5. Do not disable TLS verification. Solve it with the corporate root certificate instead.

If only DSH still fails after configuration while sibling CLIs work, align the proxy variables and Node versions item by item between the two; the difference is usually the cause.See DeepSeek Harness env: git config, PAT, proxy, creds.yaml for the related case.