[Bug][Windows] Case mismatch in node_modules causes duplicate ESM instances and profile settings save failure

[mannerismw-byte]

[Bug][Windows] Case mismatch in node_modules causes duplicate ESM instances and profile settings save failure

Summary

On Windows 11, DeepSeek Harness 0.2.0-rc.2 failed to persist Web UI settings on my machine when the actual npm global modules directory was named Node_modules (uppercase N), while npm and the initial ESM import used node_modules (lowercase n).

The application started successfully, but accepting the developer preview notice produced:

settings/rejected
dsh: profile reload requires the root Include entry

Runtime instrumentation traced the failure to two separate evaluations of @deepseek-ai/dsh-app-boot under module URLs differing in directory-name capitalization. A temporary source workaround allowed the UI to proceed. Renaming the physical directory to lowercase subsequently eliminated the measured path mismatch. After restoring the original, unmodified dsh-app-boot source, I also confirmed that the Web UI could save the confirmation successfully without the temporary source patch.

Environment

Item	Value
OS	Windows 11 Pro x64
Node.js	v24.21.0
npm	11.19.0
DeepSeek Harness	0.2.0-rc.2
Installation	npm install -g @deepseek-ai/dsh@0.2.0-rc.2
npm global prefix	D:\Application\Node_home\Node_global
Filesystem	Case-insensitive directory (verified with fsutil)
Affected interface	DSH Web UI

Steps to reproduce

The following describes the failing setup observed on my machine:

1. Configure npm's global prefix as D:\Application\Node_home\Node_global.
2. Have the physical global modules directory named Node_modules (uppercase N).
3. Install DeepSeek Harness globally with npm.
4. Start dsh web.
5. Open the Web UI and accept the developer preview notice.
6. Observe that the confirmation cannot be persisted.

Reproduction limitation: These steps document one observed environment; they have not been independently reproduced on a clean Windows installation.

Actual vs. expected behavior

Actual: Saving the confirmation returned settings/rejected with the underlying root Include entry error.

Expected: The Web UI should persist settings even when differently capitalized path strings refer to the same directory on a case-insensitive Windows filesystem.

Investigation and evidence

1. Two separate module evaluations

Temporary instrumentation in dsh-app-boot/lib/index.js recorded two module initialization events during one DSH Web session. Both had the same process ID, threadId: 0, and referred to the same file on disk, but they had different import.meta.url values:

Instance 1:
.../Node_global/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js

Instance 2:
.../Node_global/Node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js

2. Root Include state was not shared

Instrumentation of the module-level bootstrapIncludes WeakMap showed:

[DSH-DIAG set] { instance: 1, entryDefined: true, registeredHere: true }

[DSH-DIAG get] {
  instance: 2,
  registeredHere: false,
  registrations: [ { sameContext: true, instance: 1, entryDefined: true } ]
}

The same Context object had been registered in the first module instance, but the reload path accessed a different instance with a separate WeakMap.

3. Second import originated from Cordis Loader

The stack from the second module evaluation included:

@deepseek-ai/cordis-plugin-loader/lib/index.js:218
Entry._init
Entry.init
Entry.update
EntryGroup.create

The loader delegates imports through:

this.ctx.loader.internal.import(name, this.ctx.baseUrl, {});

4. Path canonicalization mismatch

The installed dsh-app-boot version contains:

function realModuleDirectory(path) {
  return isPackagedExecutable()
    ? realpathSync(path)
    : realpathSync.native(path);
}

With the physical directory named Node_modules, the following local test returned:

Input:
D:\Application\Node_home\Node_global\node_modules

fs.realpathSync:
D:\Application\Node_home\Node_global\node_modules

fs.realpathSync.native:
D:\Application\Node_home\Node_global\Node_modules

The native realpath output matched the capitalization of the second module URL. Together with the runtime instrumentation, this supports a path-identity mismatch as the cause of the separate ESM module instances in this execution.

Local verification and workarounds

Workaround A: Temporary local code change

I temporarily replaced:

return isPackagedExecutable()
  ? realpathSync(path)
  : realpathSync.native(path);

with:

return realpathSync(path);

After the change, the Web UI advanced past the developer preview notice to the API key configuration screen. This was a diagnostic workaround, not a proposed final cross-platform fix.

Workaround B: Normalize the physical directory name

I then renamed the physical npm global modules directory from Node_modules to node_modules and aligned the NODE_PATH setting. Both path resolution functions subsequently returned:

D:\Application\Node_home\Node_global\node_modules

This eliminated the observed capitalization discrepancy without requiring the directory names of its parent folders to be changed. I then restored the original dsh-app-boot source from the pre-patch backup and verified that the Web UI confirmation could be saved successfully without the temporary code change.

Final verification and limitations

• The original settings failure was reproducible on my Windows 11 machine before local changes.
• The temporary source change allowed the Web UI to proceed to API key configuration.
• Renaming the physical directory removed the difference between realpathSync() and realpathSync.native() outputs.
• After restoring the original, unmodified dsh-app-boot source, I confirmed that the Web UI could save the developer-preview confirmation successfully. This verifies the filesystem-only workaround on my machine, without a permanent source patch.
• An independent reproduction on a clean Windows installation has not been performed.
• macOS and Linux have not been tested.

Suggested investigation

Please consider using consistent module-URL canonicalization across initial ESM imports and dynamic plugin imports on Windows. A regression test could cover:

• Case-insensitive Windows filesystems.
• A physical dependency directory named Node_modules when callers use node_modules.
• Initial and dynamic imports of the same package.
• Shared module-local state during initialization and profile reload.
• Successful persistence of Web UI settings.

Simply replacing realpathSync.native() with realpathSync() globally may have unintended cross-platform effects; a tested resolution strategy would be preferable.

Related discussions

• #7675 — Related Windows path-capitalization and duplicate ESM module-instance behavior.
• #8928 — Related root Include entry failure and module-state investigation.

This report documents an additional observed trigger involving the physical capitalization of the npm global node_modules directory.

I can provide sanitized logs, an isolated reproduction, or test a proposed fix if helpful.

Thanks for maintaining DeepSeek Harness!