bug(sandbox): OpenClaw v2026.4.24 onboard/plugins CLI hangs under OpenShell 0.0.34 unless bundled plugins are disabled

[derekhsu]

Agent Diagnostic

• Investigated the regression by reading OpenClaw CLI/plugin loader source and reproducing behavior inside an OpenShell sandbox.
• Confirmed that the hang is not limited to openclaw onboard; openclaw plugins --help also hangs inside the sandbox.
• Confirmed that the following workaround unblocks both commands:
  • OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 openclaw onboard --help
  • OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 openclaw plugins --help
• Confirmed that direct manifest-related helper calls are fast, which suggests the hang is not in simple manifest parsing itself:
  • loadPluginManifestRegistry() path appears fast
  • provider-auth/onboard flag resolution appears fast
• Narrowed the problem to bundled plugin loading / registration paths, especially the runtime-dependency staging path used by packaged bundled plugins.
• Observed that packaged bundled plugins may install runtime dependencies into:
  • /sandbox/.local/state/openclaw/plugin-runtime-deps
• Verified that, in the sandbox, this state directory starts empty (so first-run staging is plausible).
• Verified that npm itself is available in the sandbox and a small manual install succeeds, so this is not a blanket “npm is unreachable” failure.
• Open question: whether the command is truly deadlocked, or is spending a very long time loading/staging bundled plugin runtime dependencies with no user-visible output.
• Relevant OpenClaw-side finding: the regression strongly correlates with bundled plugin loading, because disabling bundled plugins immediately restores responsiveness.
• Relevant OpenShell-side context: the regression boundary reported by the user is OpenShell 0.0.33 -> 0.0.34 while keeping the OpenClaw image payload effectively the same (derekhsu/openshell-openclaw:2026.4.24, containing OpenClaw v2026.4.24).
• Most relevant OpenShell release changes in v0.0.34 appear to be:
  • fix(sandbox): apply supervisor seccomp prelude (fix(sandbox): apply supervisor seccomp prelude #891)
  • fix(sandbox): canonicalize HTTP request-targets before L7 policy evaluation (fix(sandbox): canonicalize HTTP request-targets before L7 policy evaluation #878)
• I do not yet have a proof that either of those two OpenShell changes is the root cause. The strongest current evidence is that OpenClaw bundled plugin loading behaves differently / stalls only when run under OpenShell 0.0.34 sandboxing.

Description

When running OpenClaw inside an OpenShell 0.0.34 sandbox, openclaw onboard appears to hang with no response. This started after upgrading OpenShell to 0.0.34.

Important context: this is using a custom image derekhsu/openshell-openclaw:2026.4.24, but the image payload itself was not materially changed for this regression test; the main change was the OpenShell version. The OpenClaw version inside the image is v2026.4.24.

From investigation so far, the problem is broader than the onboard wizard itself. It also affects bundled-plugin-related CLI startup paths such as openclaw plugins --help.

A reliable workaround is to disable bundled plugins:

OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 openclaw onboard --help
OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 openclaw plugins --help

That strongly suggests the stall happens during bundled plugin discovery / registration / runtime dependency staging when OpenClaw starts inside the OpenShell sandbox.

Reproduction Steps

1. Use OpenShell 0.0.34.
2. Start a sandbox from an image that contains OpenClaw v2026.4.24 (in my case: derekhsu/openshell-openclaw:2026.4.24).
3. Enter the sandbox and run:

   openclaw onboard

4. Observe that the command shows no response / appears hung.
5. As a narrower repro, run:

   openclaw plugins --help

6. Observe that this also appears hung.
7. Compare with:

   OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 openclaw onboard --help
   OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 openclaw plugins --help

8. Observe that both commands return normally when bundled plugins are disabled.

Expected Behavior

openclaw onboard should start its onboarding flow promptly, and openclaw plugins --help should render help output quickly inside the sandbox.

Actual Behavior

openclaw onboard appears to hang with no response under OpenShell 0.0.34. The same class of behavior also affects openclaw plugins --help.

Environment

• Host OS: macOS (Apple Silicon)
• OpenShell version: openshell 0.0.34
• Sandbox image: derekhsu/openshell-openclaw:2026.4.24
• OpenClaw version inside image: v2026.4.24 (user-provided image payload version)
• Network/proxy context inside sandbox:
  • HTTP_PROXY=http://10.200.0.1:3128
  • HTTPS_PROXY=http://10.200.0.1:3128
  • NO_PROXY=127.0.0.1,localhost,::1

Logs

Observed command behavior / evidence:

$ openshell --version
openshell 0.0.34

# inside sandbox: small npm install works, so npm is not blanket-broken
$ node -e 'const {spawnSync}=require("child_process"); const fs=require("fs"); const dir="/sandbox/tmp-npm-probe"; fs.mkdirSync(dir,{recursive:true}); fs.writeFileSync(dir+"/package.json", JSON.stringify({name:"probe",private:true})); const r=spawnSync("npm",["install","--ignore-scripts","typebox@1.1.31"],{cwd:dir,encoding:"utf8",timeout:12000}); console.log(JSON.stringify({status:r.status,signal:r.signal,error:r.error?String(r.error):null,stdout:(r.stdout||"").slice(0,500),stderr:(r.stderr||"").slice(0,500)},null,2));'
{
  "status": 0,
  "signal": null,
  "error": null,
  "stdout": "\nadded 1 package in 952ms\n",
  "stderr": "(node:2011) [UNDICI-EHPA] Warning: EnvHttpProxyAgent is experimental, expect them to change at any time.\n..."
}

# workaround behavior
$ OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 openclaw onboard --help
# returns normally

$ OPENCLAW_DISABLE_BUNDLED_PLUGINS=1 openclaw plugins --help
# returns normally

Additional source-level diagnostic notes:

• direct manifest registry loading and provider-auth flag resolution appear fast
• the suspicious area is bundled plugin load/registration and packaged-plugin runtime dependency staging
• packaged bundled plugins appear to use /sandbox/.local/state/openclaw/plugin-runtime-deps for staged runtime dependencies

Why I think this belongs in OpenShell

I am not certain the root cause is purely in OpenShell, but the regression boundary is currently OpenShell 0.0.34, while the OpenClaw image payload was held effectively constant.

Even if the ultimate fix ends up needing coordination with OpenClaw, it would be helpful to investigate whether 0.0.34 changed sandbox runtime behavior in a way that causes OpenClaw bundled plugin startup to stall or become extremely slow.

Potential places to inspect:

• sandbox behavior differences between 0.0.33 and 0.0.34

• any 0.0.34 interactions with OpenClaw’s packaged bundled-plugin startup path

• whether first-run bundled runtime dependency staging in sandboxed environments needs different visibility / timeouts / policy behavior

• I pointed my agent at the repo and had it investigate this issue

• I loaded relevant skills / workflows for repository and issue investigation

• My agent could not fully resolve this — the diagnostic above explains why