[Windows] Case-duplicate proxy variables in the child environment break PowerShell Env: provider

[ssjob123]

[Windows] Case-duplicate proxy variables in the child environment break PowerShell's Env: provider (Get-ChildItem Env: throws "An item with the same key has already been added.")

Summary

On Windows, @deepseek-ai/dsh-http-proxy publishes both casings of each proxy variable (http_proxy and HTTP_PROXY) into the environment object handed to spawned children, so the child's Windows environment block contains case-duplicate names and PowerShell's case-insensitive Env: provider throws An item with the same key has already been added. — making Get-ChildItem Env: / Get-Item Env:PATH / ls Env: unusable inside the DSH shell tool.

Environment

• DSH: @deepseek-ai/dsh 0.1.5-rc.1 (npm global install) — reproduced on this version.
• Not fixed on master or on the latest release dsh-v0.1.5-rc.2 (verified 2026-09-12: packages/util/http-proxy/src/policy.ts is byte-identical on both refs and still declares both casings for every field).
• Node.js: v26.4.0. The defect is not Node-version specific — the duplicate originates in the plain JS env object handed to spawn, not in version-specific Node behaviour — so Node 24+ behaves the same.
• OS: Windows 11 Home (Chinese), build 26200, x64.
• Shell: Windows PowerShell 5.1 (no PowerShell 7 / pwsh installed on this host).

Steps to reproduce

1. Export any proxy variable in either casing, e.g.:

setx HTTP_PROXY http://127.0.0.1:7890

(Any export mechanism works. No proxy actually needs to be listening — the variable merely has to exist. HTTPS_PROXY, NO_PROXY and the lowercase spellings trigger it identically.)
2. Close and reopen the terminal so the new value is present in the process environment block.
3. Start DSH:

dsh web

4. In the DSH session, run through the shell tool:

Get-ChildItem Env:

Expected behaviour

Get-ChildItem Env: lists the environment variables of the spawned PowerShell process, as it does in any terminal outside DSH.

Actual behaviour

PS> Get-ChildItem Env:
Get-ChildItem : An item with the same key has already been added.
At line:1 char:1
+ Get-ChildItem Env:
+ ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-ChildItem], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException,Microsoft.PowerShell.Commands.GetChildItemCommand

Get-Item Env:PATH and ls Env: fail the same way. In the very same session the following both work, which isolates the fault to the Env: provider rather than to the environment block itself:

$env:PATH                                                  # works
[System.Environment]::GetEnvironmentVariable('PATH')       # works

Impact: the agent's own PowerShell tool cannot enumerate environment variables. Any model-authored script that touches Get-ChildItem Env: fails, which triggers retries and stalls. This is a known Windows/PowerShell failure mode for duplicated case-variant names (upstream: PowerShell/PowerShell#6305).

Root cause

1. packages/util/http-proxy/src/policy.ts declares both casings for every policy field:

/**
 * The environment names each policy field owns, lowercase first — undici reads the lowercase name
 * first, so both casings are always written or cleared together.
 */
export const POLICY_ENV_NAMES = {
  httpProxy: ['http_proxy', 'HTTP_PROXY'],
  httpsProxy: ['https_proxy', 'HTTPS_PROXY'],
  noProxy: ['no_proxy', 'NO_PROXY'],
} as const

On 0.1.5-rc.1 (and earlier) this constant lived in the sibling module packages/util/http-proxy/src/install.ts; it was moved to policy.ts, unchanged, on master. So on the reporter's version the same constant and the same applyPolicyEnv are in install.ts.

2. applyPolicyEnv(policy) in install.ts writes both spellings into process.env. On Windows this layer is harmless on its own, because Node's process.env folds names case-insensitively — which writeProxyEnv() in the same file already documents:

// Snapshot EVERY name before writing any of them. Windows folds environment names case-insensitively,
// so reading the uppercase spelling after writing the lowercase one would read back the value just
// written and restore the policy instead of the user's environment.

3. But proxyEnvironmentForChild() returns a plain JS object, which is case-sensitive, and assigns one entry per spelling:

const overlay: Record<string, string | undefined> = { NODE_USE_ENV_PROXY: '1' }
for (const [field, names] of Object.entries(POLICY_ENV_NAMES)) {
  const resolved = policy[field as keyof typeof POLICY_ENV_NAMES]
  const named = field !== 'noProxy' && names.some(name => inherited[name] !== undefined)
  for (const name of names) overlay[name] = named ? inherited[name] : resolved
}

overlay['http_proxy'] and overlay['HTTP_PROXY'] are two distinct properties here.

4. packages/util/subprocess/subprocess/src/index.ts — scrubbedParentEnv() (published as @deepseek-ai/dsh-subprocess/lib/index.js) builds the child base with a plain object and then merges that overlay onto it:

export function scrubbedParentEnv(): Record<string, string> {
  const env: Record<string, string> = {}
  for (const [key, value] of Object.entries(process.env)) {
    if (value !== undefined && !SENSITIVE_ENV_PATTERN.test(key) && !key.toUpperCase().startsWith(DSH_ENV_PREFIX)) env[key] = value
  }
  // restores each proxy name to what the user exported, undoing this process's own normalization —
  // `undefined` removes a name the user never set.
  for (const [name, value] of Object.entries(proxyEnvironmentForChild())) {
    if (value === undefined) Reflect.deleteProperty(env, name)
    else env[name] = value
  }
  return env
}

Enumerating process.env on Windows yields the user's spelling exactly once (e.g. HTTP_PROXY), while the overlay contributes http_proxy as a new key of a case-sensitive object. The object returned to spawn therefore carries both HTTP_PROXY and http_proxy.

5. Windows CreateProcess accepts case-variant duplicates in lpEnvironment and does not deduplicate them, so the PowerShell child really does receive two entries whose names differ only in case.

6. Windows PowerShell 5.1 implements Env: over a case-insensitive dictionary and throws ArgumentException: An item with the same key has already been added. when the second variant is inserted.

Why this cannot be turned off

runProfile() in apps/cli/src/profile-boot.ts installs the proxy unconditionally:

const disposeProxy = await installProxyFromEnvironment(options.environment, (message) => {
  process.stderr.write(...)
})

That call happens before composeProfile() loads cordis.patch.yml, so a profile patch cannot prevent it. dsh-http-proxy is a plain library (its README states no mounting and no configuration are required), not a plugin line, so the loader's disabled mechanism does not apply. There is also no proxy-related DSH_* switch anywhere in the project (only DSH_HOME, DSH_TELEMETRY_DISABLED, DSH_SNAPSHOT and the internal DSH_LAUNCH_ENVIRONMENT_KEY).

In-repo precedent for the fix

The sibling package already solves exactly this problem: packages/util/launch-environment/README.md states that "on Windows, names are folded to uppercase before storage so case variants cannot split precedence", and packages/util/launch-environment/src/index.ts implements it:

return process.platform === 'win32' ? name.toUpperCase() : name

dsh-http-proxy's child overlay is the one path that bypasses that protection.

Suggested fix

Any one of these resolves it; the first matches the precedent already in the repo:

1. Emit a single spelling per platform in proxyEnvironmentForChild(). Writing both casings exists only to satisfy undici's "lowercase wins" read order; on Windows the environment is case-insensitive anyway, so the duplicate buys nothing. Select the spelling by process.platform (uppercase on win32), or reuse the dsh-launch-environment folding rule instead of hand-rolling names.
2. Fold/deduplicate in scrubbedParentEnv(). When building the child env on win32, collapse keys case-insensitively so no upstream overlay can ever produce a duplicate. This is the more robust place, since scrubbedParentEnv is the single shared base for every spawner.
3. Add an opt-out. A DSH_* switch that suppresses proxy-environment publication to children would help as a stopgap — but it must be evaluated after composeProfile() so a profile patch can actually set it.

A regression test worth having: on win32, assert that Object.keys(scrubbedParentEnv()) contains no two entries equal under toUpperCase().

Workaround

Clear every casing before starting dsh, e.g. via a wrapper script:

Remove-Item Env:HTTP_PROXY,  Env:HTTPS_PROXY,  Env:NO_PROXY  -ErrorAction SilentlyContinue
Remove-Item Env:http_proxy,  Env:https_proxy,  Env:no_proxy  -ErrorAction SilentlyContinue
dsh web

Note that the uppercase and the lowercase spelling each trigger the bug independently, so all six names must be cleared. Alternatively, use a terminal dedicated to DSH in which no proxy variable is exported.

[PerryLink]

核实到的部分：dsh-http-proxy 的策略层显式折叠两种大小写 —— packages/util/http-proxy/src/policy.ts:40：httpProxy: ['http_proxy', 'HTTP_PROXY']；boot 层的环境白名单用大写（packages/boot/app-boot/src/index.ts:111）。这与「管道里同时存在两种大小写」的报告吻合。

子进程环境最终如何把两份都发布出去、以及 PowerShell Env: 崩溃的确切触发点，我没有逐行钉死 —— 如果你把报错原文（Get-ChildItem Env: 的完整输出）贴出来，可以精确到行。你的修复方向（子环境统一为单一大小写）与 boot 层白名单思路一致。（基于 0.1.5-rc.2 源码核对。）