Web settings save fails: "profile reload requires the root Include entry" (dsh 0.2.0-rc.2, empty profile root)

[LUgABeEEE]

Environment

• @deepseek-ai/dsh 0.2.0-rc.2 (web), @deepseek-ai/dsh-app-boot 0.2.0-rc.2, @deepseek-ai/cordis-plugin-loader 1.0.5, @deepseek-ai/dsh-llm-pi-ai 0.2.0-rc.2
• Node v22.22.0, Linux (Ubuntu 24.04)
• Started via dsh web --port <port> --trusted-host <host>
• Profile: <DSH_HOME>/profiles/<profile>/, composed from package.json → dsh.profile.bundles + cordis.patch.yml

Summary

With a profile whose root config file is the shipped default empty entry list:

# <profile>/cordis.yml
# dsh profile root — an empty entry list. The tree is composed as patches:
# each bundle in package.json's dsh.profile.bundles, then cordis.patch.yml, then any
# --patch overlays. Edit cordis.patch.yml, not this file.
[]

every save from the Web settings page (Settings → Models) fails, and nothing is persisted:

dsh: profile reload requires the root Include entry

Steps to reproduce

1. Start the web app against a profile whose cordis.yml is [] (the default template above).
2. Open the Web UI → Settings → Models.
3. Change anything (e.g. edit a provider's base URL, or try to add a custom provider), press save.

Expected: the change is applied (and hot-reloaded).
Actual: dsh: profile reload requires the root Include entry; the edit is rolled back; the models page cannot be used to configure providers at all.

Root cause (code reading)

1. The save path is @deepseek-ai/dsh-config-editor → ConfigEditor.edit():

   const beforePatches = readProfilePatches("dsh", this.ownerContext.profileContext);
   await reconcileProfilePatches(this.ownerContext.root, beforePatches, "dsh");

2. reconcileProfilePatches() (packages/boot/app-boot) requires a registration that only
   bootstrap performs:

   async function reconcileProfilePatches(ctx, patches, binName, requiredIds = []) {
     const entry = bootstrapIncludes.get(ctx);
     if (entry === void 0) throw new Error(`${binName}: profile reload requires the root Include entry`);
     …
   }

3. That registration happens in mountRootInclude():

   const rootInclude = { id: "include", name: "cordis:include",
                         config: { path: pathToFileURL(absoluteConfigPath).href, …patches } };
   const includeId = await ctx.loader.create(rootInclude);
   const loader = ctx.get("loader");
   if (loader === void 0) return void 0;          // ← early return: nothing is registered
   const entry = loader.resolve(includeId);
   bootstrapIncludes.set(ctx, entry);             // ← module-level WeakMap keyed by the boot ctx

   So if the loader service is not resolvable at that moment, or if the later reload runs against a
   context other than the one that boot registered, the WeakMap lookup misses for every subsequent
   reload — which makes the whole settings-write feature (and dsh-hmr / dsh-plugin-manager, which
   call the same function) unusable for that deployment.

Suggested directions

• In mountRootInclude, fail loudly (or retry) instead of silently returning when ctx.get("loader")
  is undefined — today it produces a boot that looks healthy but can never reload.
• In reconcileProfilePatches, fall back to (re)mounting the root include when the lookup misses,
  rather than throwing.
• Or key the registration by profile/root (e.g. the absolute profile path) instead of the ctx
  instance, so any ctx belonging to that profile can reconcile.
• The thrown message is terse; mentioning that it is a bootstrap-registration miss (and that settings
  saves will keep failing) would save users a long debugging session.

Impact

On such a deployment the Web UI cannot add or modify providers/credentials-bearing settings; the only
workaround is to edit cordis.patch.yml by hand and restart the process. This blocks a documented,
first-class feature (adding a custom OpenAI-compatible provider from the browser).

[ltxhhz]

Run where.exe dsh and check if the drive letter is lowercase. If it is, update it to uppercase in the PATH environment variable.
This is how I resolved it.