Embeddings silently disabled for upgrading users (HIVEMIND_EMBEDDINGS unset → enabled=false)

Start in src/user-config.ts, especially migrationValueFromEnv() and getEmbeddingsEnabled(), using the lines referenced in the issue to trace how an undefined HIVEMIND_EMBEDDINGS is handled. Next check where the config migration writes ~/.deeplake/config.json and confirm why {embeddings:{enabled:false}} becomes sticky. Reproduce with a fresh/no-config upgrade path and no env var, then verify the first call keeps embeddings enabled by default unless the user explicitly opts out. Done when enabled is no longer written false just because the env var is unset.

Symptom

Users upgrading past bfc8e07 (and fresh installs that don't set HIVEMIND_EMBEDDINGS=true) get embeddings persistently disabled on first SDK call. ~/.deeplake/config.json ends up with {embeddings: {enabled: false}} forever — until the user explicitly runs hivemind embeddings install (which writes enabled: true).

Root cause

src/user-config.ts:67 documents the migration rule as:

HIVEMIND_EMBEDDINGS=false OR unset → enabled: false
HIVEMIND_EMBEDDINGS=true (or any other truthy) → enabled: true

And migrationValueFromEnv() at line 96 implements that literally:

if (raw === undefined) return false;

So on first call to getEmbeddingsEnabled() (no config yet, env var unset), it returns false and persists that to disk. The decision becomes sticky.

Impact

• Users who had working embeddings before upgrading silently lose semantic memory search
• No banner fires because the embeddings-broken signal is the one we removed in #182
• Discovery requires the user to notice grep/recall feels degraded and find the CLI command

Suggested fix

Per CodeRabbit on #182:

 function migrationValueFromEnv() {
   const raw = process.env.HIVEMIND_EMBEDDINGS;
-  if (raw === undefined) return false;
+  if (raw === undefined) return undefined;
   if (raw === "false") return false;
   return true;
 }

And update getEmbeddingsEnabled() to treat undefined from migration as "default true" (no opt-out signal present).

Why not in PR #182

#182's scope is the user-visible banner removal. Changing the migration default touches Emanuele's intentional design rule (bfc8e07) — needs his judgment call on opt-in vs opt-out.

Related

• PR #182 (banner removal) — surfaces this regression because there's now no audible "embeddings off" signal
• bfc8e07 (feat(embeddings): hello handshake + stuck-daemon recycle + visible signal) — where the rule was introduced
• @emanuele-fenocchi-activeloop's call on the design