openclaw - 💡(How to fix) Fix `prepareContextEngineSubagentSpawn` calls `resolveContextEngine` without initializing the registry — fails 100% on cliBackend-only installs [1 participants]

Affected version

OpenClaw 2026.4.24 (build cbcfdf6), installed via pnpm. Likely affects any version that bundles the lazy-init pattern shown below.

Symptom

First (and every) mcp__openclaw__sessions_spawn call on an install that routes chat through cliBackends (Anthropic CLI backend, OAuth-mode auth profile) returns:

{
  "status": "error",
  "error": "Context engine subagent preparation failed: Context engine \"legacy\" is not registered. Available engines: (none)",
  "childSessionKey": "agent:main:subagent:<uuid>"
}

The error never appears in gateway.err.log — it's returned over the RPC response, not file-logged (line 423 of subagent-spawn-BxkfDpwx.js builds the error string and returns it via the spawn-prep result).

Repro

1. Configure OpenClaw with cliBackends-routed chat (e.g., embeddedHarness.runtime: "claude-cli", cliBackends.claude-cli populated, auth.profiles.anthropic:claude-cli set to OAuth mode).
2. Restart gateway from cold (no prior pi-embedded activation in the running process).
3. Invoke any sessions_spawn — first time fails as above. The chat path itself works fine because cli-backend bypasses the context-engine registry entirely.

Root cause

dist/subagent-spawn-BxkfDpwx.js:405–425 defines prepareContextEngineSubagentSpawn:

import { i as resolveContextEngine } from "./registry-CWj0q4ZO.js";
// ...
async function prepareContextEngineSubagentSpawn(params) {
  try {
    return {
      status: "ok",
      preparation: await (await subagentSpawnDeps.resolveContextEngine(params.cfg)).prepareSubagentSpawn?.({...})
    };
  } catch (err) {
    return { status: "error", error: `Context engine subagent preparation failed: ${summarizeError(err)}` };
  }
}

It imports resolveContextEngine directly from registry-CWj0q4ZO.js and calls it against an empty registry. There's no call to ensureContextEnginesInitialized from init-Cvj1-B8f.js.

init-Cvj1-B8f.js:36–57 shows the legacy engine registration is lazy:

function registerLegacyContextEngine() {
    registerContextEngineForOwner("legacy", async () => new LegacyContextEngine(), "core", { allowSameOwnerRefresh: true });
}
let initialized = false;
function ensureContextEnginesInitialized() {
    if (initialized) return;
    initialized = true;
    registerLegacyContextEngine();
}

Importing init-Cvj1-B8f.js does NOT register legacy — only calling ensureContextEnginesInitialized() does. Two call sites do this: pi-embedded-Cic3zlxn.js:75,1720 and subagent-registry-Cx_UMX3T.js:1227. Neither is in the spawn-prep code path.

Why it bites only some users

Installs that route chat through pi-embedded.js (the default for non-cliBackends setups) call ensureContextEnginesInitialized() on every chat turn — so the legacy engine is registered well before any subagent spawn. Installs that route chat through cli-backend (subprocess invocation of the claude binary) never enter pi-embedded.js, so the registry stays empty until the first sessions_spawn arrives — and that call is the cold reader.

Suggested fix

Add a single import + a single call to the spawn-prep path in subagent-spawn-BxkfDpwx.js:

+ import { t as ensureContextEnginesInitialized } from "./init-Cvj1-B8f.js";

  async function prepareContextEngineSubagentSpawn(params) {
+     ensureContextEnginesInitialized();
      try {
          return { status: "ok", preparation: ... };
      } ...
  }

This is the minimal local patch we've been running successfully for ~24h. A more architectural fix would be to make the legacy-engine registration a top-level side-effect in init-Cvj1-B8f.js so it fires on first import — but that has wider implications for chunk-bundling.

Adjacent

• #40232 — Plugin context engines can resolve before plugin registration (same root-cause family — resolve-before-init ordering)
• #39725 / #40115 — Context engine plugins not registered before agent bootstrap (boot-md fails)
• Commit f04e045 — fix(context-engine): restore bundled legacy engine loading — appears to have addressed a similar symptom previously; current bundle suggests this code path was missed in that fix

Workspace context (for repro fingerprinting)

• Workspace is cliBackends-only (no PI warm-up via chat path)
• 16 GB Apple Silicon, macOS Tahoe
• Auth profile anthropic:claude-cli in OAuth mode
• Gateway started fresh ~24h ago via openclaw configure wizard