headless profile fails to boot: "--expose-internals is required for HMR service"

[abcdok]

Environment

• macOS 10.15.7 (x86_64), Node v22.23.2
• @deepseek-ai/dsh 0.1.0-rc.6 (installed via npm i -g)
• In-box bundles: @deepseek-ai/dsh-base, @deepseek-ai/dsh-headless 0.0.1-rc.1

Repro

dsh --profile headless "say hi"

Result

Boot fails before any LLM call is made:

Error: failed to apply loader entry 7907c9d6 (@deepseek-ai/cordis-plugin-hmr): --expose-internals is required for HMR service
    at updateError (.../cordis-plugin-loader/lib/index.js:299:9)
    at Entry._init (.../cordis-plugin-loader/lib/index.js:519:10)
    at async Entry.init (.../cordis-plugin-loader/lib/index.js:495:4)
    at async Entry.update (.../cordis-plugin-loader/lib/index.js:416:37)
    at async EntryGroup.create (.../cordis-plugin-loader/lib/index.js:55:4)
    at async Proxy.create (.../cordis-plugin-loader/lib/index.js:217:14)
    at async runProfile (.../dsh/lib/profile-boot-*.js:259:4)

Analysis

The headless bundle's cordis.patch.yml already disables the HMR row:

- id: hmr
  disabled: true

and dsh --profile headless --dump-config correctly shows the composed row as id: hmr with disabled: true. However, at runtime the loader still initializes a @deepseek-ai/cordis-plugin-hmr entry first — the failing entry id is a hash that changes between runs (6696ebe1, then 7907c9d6), not the hmr id the patch targets — and its constructor throws before the headless patch layer's disable takes effect. Hypothesis: the base-bundle row is initialized while the base layer is applied, so the constructor error wins before later patch layers (which disable it) are processed.

Workaround

node --expose-internals "$(which dsh)" --profile headless "say hi"