[Bug][Windows] Desktop packaging always fails: vswhere: ProgramFiles(x86) is not set (env object loses case-insensitivity)

[lb1192176991-lab]

Summary

pnpm run package:desktop:win:x64:unsigned cannot succeed on any Windows host at 0.2.0-rc.1. The toolchain preflight aborts the run in the configuration/toolchain stage before anything is built:

$ tsx scripts/package-target.ts win-x64 --unsigned
desktop package: win-x64 publishes 0.2.0-rc.1
DESKTOP_PACKAGING_RECORD D:\...\packaging-runs\....json
Error: desktop package: the build host cannot run this packaging sequence:
  vswhere: ProgramFiles(x86) is not set, so Visual Studio cannot be located
    at requireDesktopToolchain (apps/desktop/scripts/desktop-toolchain-preflight.ts:1:2484)
    at packagingStep (apps/desktop/scripts/packaging-step.mjs:19:20)

Visual Studio C++ Build Tools are installed and vswhere.exe is present at the expected path. The message is a false negative.

Root cause

apps/desktop/scripts/desktop-package-environment.mjs rebuilds the environment as a plain object:

return {
  ...Object.fromEntries(Object.entries(environment).filter(([name]) => !AMBIENT_RELEASE_SETTING.test(name))),
  ...settings,
}

On Windows, process.env is a case-insensitive proxy, but Object.entries() only yields the canonicalised uppercase key names. So the rebuilt object contains PROGRAMFILES(X86) and not ProgramFiles(x86). Because the new object is a plain Object, the case-insensitivity is gone.

Downstream, desktop-toolchain-preflight.ts does an exact-match lookup:

const programFiles = environment['ProgramFiles(x86)']   // -> undefined
const vswhere = programFiles === undefined
  ? undefined
  : join(programFiles, 'Microsoft Visual Studio/Installer/vswhere.exe')
if (vswhere === undefined) {
  failures.push({ tool: 'vswhere', detail: 'ProgramFiles(x86) is not set, ...' })
}

undefined is returned, so the probe reports VS as missing even though it is installed.

Instrumenting that exact line confirms it:

[DEBUG] matching keys: COMMONPROGRAMFILES, COMMONPROGRAMFILES(X86), PROGRAMFILES, PROGRAMFILES(X86)
[DEBUG] environment['ProgramFiles(x86)'] = undefined
[DEBUG] process.env['ProgramFiles(x86)']  = "C:\Program Files (x86)"   <-- present here
[DEBUG] environment === process.env       = false

Note this is not a shell issue. It reproduces under native cmd.exe as well as git-bash/MSYS, and injecting the variable with env "ProgramFiles(x86)=..." does not help, because loadDesktopPackageEnvironment() discards the ambient value when it rebuilds the object.

Reproduction

Any Windows host with VS Build Tools installed:

cp apps/desktop/.env.windows.example apps/desktop/.env.windows
# fill in the mandatory-update origins (separate prerequisite, see below)
cd apps/desktop
node ../../node_modules/tsx/dist/cli.mjs scripts/package-target.ts win-x64 --unsigned --check
# -> Error: ... vswhere: ProgramFiles(x86) is not set ...

Suggested fix

Restore case-insensitive lookup on the returned object for the win32 platform, e.g. wrap it in a Proxy that falls back to an uppercase-keyed map:

const merged = {
  ...Object.fromEntries(Object.entries(environment).filter(([name]) => !AMBIENT_RELEASE_SETTING.test(name))),
  ...settings,
}
if (platform === 'win32') {
  const normalized = new Map(Object.entries(merged).map(([name, value]) => [name.toUpperCase(), value]))
  return new Proxy(merged, {
    get(target, property, receiver) {
      if (typeof property === 'string' && !Reflect.has(target, property)) {
        const hit = normalized.get(property.toUpperCase())
        if (hit !== undefined) return hit
      }
      return Reflect.get(target, property, receiver)
    },
    has(target, property) {
      if (typeof property === 'string' && !Reflect.has(target, property)) return normalized.has(property.toUpperCase())
      return Reflect.has(target, property)
    },
  })
}
return merged

Alternatively, have the preflight read the variable case-insensitively (or reuse process.env for platform tooling paths instead of the file-owned release settings object).

With the patch above, --check passes and a full unsigned package builds successfully:

desktop package: win-x64 would publish 0.2.0-rc.1; local configuration and toolchain valid, signing and notarization were not attempted
...
deepseek-harness-0.2.0-rc.1-win-x64-unsigned.exe   (274 MB)

Environment

• DSH 0.2.0-rc.1 (commit 4878cdabd8), Windows 10 x64, Node v24.15.0
• VS 2022 Build Tools at D:\VSBuildTools, Windows SDK 10.0.26100

Note

While packaging I also had to satisfy a separate prerequisite that the template leaves empty — worth documenting for anyone attempting a local unsigned build:

DSH_DESKTOP_AUTO_UPDATE_ENV=test
DSH_DESKTOP_MANDATORY_UPDATE_TEST_ORIGIN=https://policy.local.invalid
DSH_DESKTOP_MANDATORY_UPDATE_CONFIG='{"allowedAuthOrigins":["https://login.local.invalid"]}'

validateDesktopPackageEnvironment rejects an empty origin (requires an HTTPS origin) even for unsigned / preparation-only builds, and test mode additionally requires a non-empty allowedAuthOrigins.

Happy to verify a fix if a branch is ever published. Thanks for the release — everything else about 0.2.0-rc.1 is working well here.