Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
OpenClaw expects writable /app in containers, which is often not the case in production-grade Kubernetes environments. Observed under OpenShift restricted SCC, and likely relevant to Kubernetes/container deployments that run as non-root, treat the packaged app tree as immutable, use read-only roots, or restrict writable state/cache paths. With
Steps to reproduce
Environment
- OpenClaw:
2026.4.23
- Runtime: OpenShift / Kubernetes
- Security context: restricted SCC-style environment
- Packaged app path:
/app
/app is readable but not writable by the runtime user
- Persistent state/home under
/home/node/.openclaw
- npm user-level prefix configured to
/home/node/.openclaw so global/user installs do not target an immutable packaged application path
- Current relevant plugin state during later OpenShift tests:
acpx: enabled
active-memory: disabled again after timeout/noise testing
telegram: enabled and working
discord: enabled and able to initialize
Packaged filesystem contrast
In a fresh Podman container, /app is writable by the runtime user:
node@container:/app$ touch stuff
node@container:/app$ ls
dist docs extensions node_modules openclaw.mjs package.json qa skills stuff
In the OpenShift pod, /app is not writable:
$ pwd
/app
$ touch stuff
touch: cannot touch 'stuff': Permission denied
This distinction matters because production/container deployments commonly treat the packaged app tree as immutable. Runtime scratch/cache writes are fine when they go to explicit writable locations (/tmp, configured cache/state dirs, mounted volumes), but bundled plugin loading should not depend on mutating /app, /app/dist/extensions/..., or npm-global package directories.
This is also why the OpenShift deployment configures npm's prefix under /home/node/.openclaw: in a restricted container, npm global/user installs need to land in persistent writable state rather than the packaged application tree. That should make dynamic installs safer, but it may expose places where OpenClaw's own bundled runtime-deps staging, npm cache handling, and npm's configured prefix are not using the same path contract.
A Podman bridge test can reproduce the filesystem condition without OpenShift. Running the image as a non-root arbitrary UID with a writable .openclaw volume gives the expected permissions:
$ touch /app/stuff
touch: cannot touch '/app/stuff': Permission denied
$ touch /home/node/.openclaw/stuff
# succeeds
Starting the gateway in that setup with --allow-unconfigured then fails bundled plugin runtime-dep installation due to npm cache/state permissions and leaves bundled plugins disabled:
05:03:44 [gateway] starting...
05:04:02 [plugins] 2 plugin(s) failed to initialize (validation: acpx, browser). Run 'openclaw plugins list' for details.
05:04:02 [gateway] [plugins] failed to install bundled runtime deps: Error: npm error code EACCES
npm error syscall mkdir
npm error path /home/node/.npm
npm error errno EACCES
npm error Your cache folder contains root-owned files...
... (plugin=acpx, source=/app/dist/extensions/acpx/index.js)
05:04:02 [gateway] [plugins] failed to install bundled runtime deps: Error: npm error code EACCES
npm error syscall mkdir
npm error path /home/node/.npm
npm error errno EACCES
... (plugin=browser, source=/app/dist/extensions/browser/index.js)
05:04:03 [gateway] ready (3 plugins: device-pair, phone-control, talk-voice; 19.2s)
A separate CLI/plugin load in the same bridge setup also failed to resolve a bundled runtime dependency from the mirrored runtime root:
[plugins] memory-core failed to load from /app/dist/extensions/memory-core/index.js: Error: Cannot find module 'typebox'
Require stack:
- /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.23-f53b52ad6d21/dist/extensions/memory-core/index.js
Setting npm cache and prefix explicitly to writable .openclaw paths avoids the immediate npm EACCES install failure in the Podman bridge test:
export npm_config_cache=/home/node/.openclaw/npm-cache
export NPM_CONFIG_CACHE=/home/node/.openclaw/npm-cache
export npm_config_prefix=/home/node/.openclaw
export NPM_CONFIG_PREFIX=/home/node/.openclaw
mkdir -p /home/node/.openclaw/npm-cache /home/node/.openclaw/lib /home/node/.openclaw/bin
node /app/openclaw.mjs gateway --port 18789 --allow-unconfigured
With those env vars set, bundled runtime-dep installs got past the previous /home/node/.npm permission error and the gateway reached ready, although startup was slower than the default Podman case:
05:13:34 [gateway] starting...
05:13:53 [plugins] acpx installed bundled runtime deps: [email protected]
05:14:34 [plugins] browser installed bundled runtime deps: @modelcontextprotocol/[email protected], express@^5.2.1, [email protected], [email protected], [email protected], ws@^8.20.0
05:14:56 [gateway] ready (5 plugins: acpx, browser, device-pair, phone-control, talk-voice; 81.8s)
05:14:56 [plugins] embedded acpx runtime backend registered (cwd: /home/node/.openclaw/workspace)
05:15:14 [plugins] embedded acpx runtime backend probe failed: embedded ACP runtime probe failed (agent=codex; command=npx @zed-industries/codex-acp@^0.11.1; cwd=/home/node/.openclaw/workspace; ACP agent exited before initialize completed (exit=1, signal=null): WARNING: proceeding, even though we could not update PATH: Permission denied (os error 13) Error: error loading config: Permission denied (os error 13))
After stopping the gateway, node /app/openclaw.mjs plugins list in the same shell loaded 59/102 plugins and showed core bundled/provider plugins loaded, including acpx, browser, memory-core, codex, and many model providers. That suggests the explicit npm cache/prefix env fixed the immediate bundled-dep install failure in the Podman bridge. The remaining ACPX backend probe error appears to be a separate restricted-home/config/PATH permission issue in the nested npx @zed-industries/codex-acp path.
This suggests there are at least two separable concerns:
- OpenClaw should set or respect writable npm cache/prefix locations for dynamic runtime-dep installs in restricted containers.
- Even after deps are installable, OpenClaw still needs one consistent contract for where bundled runtime deps are installed, scanned, mirrored, retained, and resolved.
- ACPX/coding-agent nested runtime setup may need its own restricted-container writable-home/config/PATH handling.
Observed behavior
1. Repeated runtime-deps install sequence
During startup / CLI / user-turn paths in OpenShift, multiple bundled plugins repeatedly report runtime dependency installs:
[plugins] acpx installed bundled runtime deps: [email protected]
[plugins] anthropic installed bundled runtime deps: @mariozechner/[email protected]
[plugins] brave installed bundled runtime deps: [email protected]
[plugins] browser installed bundled runtime deps: @modelcontextprotocol/[email protected], commander@^14.0.3, express@^5.2.1, [email protected], [email protected], [email protected], ws@^8.20.0
[plugins] google installed bundled runtime deps: @google/genai@^1.50.1, @mariozechner/[email protected]
[plugins] memory-core installed bundled runtime deps: chokidar@^5.0.0, [email protected]
[plugins] openai installed bundled runtime deps: @mariozechner/[email protected], ws@^8.20.0
[plugins] tavily installed bundled runtime deps: [email protected]
[plugins] telegram installed bundled runtime deps: @grammyjs/runner@^2.0.3, @grammyjs/transformer-throttler@^1.2.1, grammy@^1.42.0, [email protected], [email protected]
This includes plugins/providers from both packaged/bundled paths and dynamically configured state. The issue does not appear limited to one plugin origin.
2. Gateway can become ready, but later paths repeat the install sequence
After re-enabling ACPX alone, the gateway restarted cleanly and ACPX reached ready:
2026-04-25T12:50:14+10:00 [gateway] ready (4 plugins: acpx, browser, memory-core, telegram; 27.1s)
2026-04-25T12:54:08.251+10:00 [plugins] embedded acpx runtime backend ready
However, the first subsequent user turn triggered another full bundled runtime-deps sequence before the agent could begin responding. This took about two minutes from user request to first assistant turn and ended with a stuck-session warning plus delayed node.list:
2026-04-25T13:13:37.841+10:00 [plugins] acpx installed bundled runtime deps: [email protected]
2026-04-25T13:13:42.392+10:00 [plugins] anthropic installed bundled runtime deps: @mariozechner/[email protected]
2026-04-25T13:13:46.970+10:00 [plugins] brave installed bundled runtime deps: [email protected]
2026-04-25T13:13:51.579+10:00 [plugins] browser installed bundled runtime deps: @modelcontextprotocol/[email protected], commander@^14.0.3, express@^5.2.1, [email protected], [email protected], [email protected], ws@^8.20.0
2026-04-25T13:13:56.285+10:00 [plugins] google installed bundled runtime deps: @google/genai@^1.50.1, @mariozechner/[email protected]
2026-04-25T13:14:00.857+10:00 [plugins] memory-core installed bundled runtime deps: chokidar@^5.0.0, [email protected]
2026-04-25T13:14:05.718+10:00 [plugins] openai installed bundled runtime deps: @mariozechner/[email protected], ws@^8.20.0
2026-04-25T13:14:10.345+10:00 [plugins] tavily installed bundled runtime deps: [email protected]
2026-04-25T13:14:14.864+10:00 [plugins] telegram installed bundled runtime deps: @grammyjs/runner@^2.0.3, @grammyjs/transformer-throttler@^1.2.1, grammy@^1.42.0, [email protected], [email protected]
2026-04-25T13:15:18.521+10:00 [diagnostic] stuck session: sessionId=unknown sessionKey=agent:main:main state=processing age=127s queueDepth=1
2026-04-25T13:15:18.539+10:00 [ws] ⇄ res ✓ node.list 62188ms ...
This suggests ACPX itself can load, but bundled runtime deps are not recognized as already satisfied across later plugin-registry/session-control paths.
3. Multiple plugin-registry passes appear to occur
With acpx and active-memory enabled, there appear to be multiple distinct plugin-registry/runtime-deps passes:
- Gateway restart/load path: small set (
acpx, browser, memory-core, telegram), then gateway ready.
- Main/control/user-turn path: full provider set (
acpx, anthropic, brave, browser, google, memory-core, openai, tavily, telegram), then delayed control responses.
- Active-memory path: another full provider set, followed by active-memory timeout far beyond its configured timeout.
Example restart/load path:
2026-04-25T13:49:38.515+10:00 [plugins] acpx installed bundled runtime deps: [email protected]
2026-04-25T13:49:43.337+10:00 [plugins] browser installed bundled runtime deps: @modelcontextprotocol/[email protected], commander@^14.0.3, express@^5.2.1, [email protected], [email protected], [email protected], ws@^8.20.0
2026-04-25T13:49:48.051+10:00 [plugins] memory-core installed bundled runtime deps: chokidar@^5.0.0, [email protected]
2026-04-25T13:49:52.753+10:00 [plugins] telegram installed bundled runtime deps: @grammyjs/runner@^2.0.3, @grammyjs/transformer-throttler@^1.2.1, grammy@^1.42.0, [email protected], [email protected]
2026-04-25T13:49:59.696+10:00 [gateway] ready (5 plugins: acpx, active-memory, browser, memory-core, telegram; 26.9s)
Example first-turn/control path after that restart:
2026-04-25T13:54:16.188+10:00 [plugins] acpx installed bundled runtime deps: [email protected]
2026-04-25T13:54:20.857+10:00 [plugins] anthropic installed bundled runtime deps: @mariozechner/[email protected]
2026-04-25T13:54:25.387+10:00 [plugins] brave installed bundled runtime deps: [email protected]
2026-04-25T13:54:29.912+10:00 [plugins] browser installed bundled runtime deps: @modelcontextprotocol/[email protected], commander@^14.0.3, express@^5.2.1, [email protected], [email protected], [email protected], ws@^8.20.0
2026-04-25T13:54:34.486+10:00 [plugins] google installed bundled runtime deps: @google/genai@^1.50.1, @mariozechner/[email protected]
2026-04-25T13:54:39.038+10:00 [plugins] memory-core installed bundled runtime deps: chokidar@^5.0.0, [email protected]
2026-04-25T13:54:43.726+10:00 [plugins] openai installed bundled runtime deps: @mariozechner/[email protected], ws@^8.20.0
2026-04-25T13:54:48.351+10:00 [plugins] tavily installed bundled runtime deps: [email protected]
2026-04-25T13:54:53.073+10:00 [plugins] telegram installed bundled runtime deps: @grammyjs/runner@^2.0.3, @grammyjs/transformer-throttler@^1.2.1, grammy@^1.42.0, [email protected], [email protected]
2026-04-25T13:55:57.276+10:00 [ws] ⇄ res ✓ node.list 62788ms ...
Example active-memory path:
2026-04-25T13:56:26.094+10:00 active-memory: agent=main session=agent:main:main activeProvider=openai-codex activeModel=gpt-5.4-mini start timeoutMs=15000 queryChars=1405
2026-04-25T13:56:30.563+10:00 [plugins] acpx installed bundled runtime deps: [email protected]
2026-04-25T13:56:35.223+10:00 [plugins] anthropic installed bundled runtime deps: @mariozechner/[email protected]
2026-04-25T13:56:39.863+10:00 [plugins] brave installed bundled runtime deps: [email protected]
2026-04-25T13:56:44.567+10:00 [plugins] browser installed bundled runtime deps: @modelcontextprotocol/[email protected], commander@^14.0.3, express@^5.2.1, [email protected], [email protected], [email protected], ws@^8.20.0
2026-04-25T13:56:49.250+10:00 [plugins] google installed bundled runtime deps: @google/genai@^1.50.1, @mariozechner/[email protected]
2026-04-25T13:56:53.890+10:00 [plugins] memory-core installed bundled runtime deps: chokidar@^5.0.0, [email protected]
2026-04-25T13:56:58.695+10:00 [plugins] openai installed bundled runtime deps: @mariozechner/[email protected], ws@^8.20.0
2026-04-25T13:57:03.306+10:00 [plugins] tavily installed bundled runtime deps: [email protected]
2026-04-25T13:57:07.893+10:00 [plugins] telegram installed bundled runtime deps: @grammyjs/runner@^2.0.3, @grammyjs/transformer-throttler@^1.2.1, grammy@^1.42.0, [email protected], [email protected]
2026-04-25T13:59:41.370+10:00 [diagnostic] stuck session: sessionId=... sessionKey=agent:main:main state=processing age=195s queueDepth=1
2026-04-25T14:00:16.650+10:00 active-memory: agent=main session=agent:main:main activeProvider=openai-codex activeModel=gpt-5.4-mini done status=timeout elapsedMs=230557 summaryChars=0
The active-memory config had timeoutMs=15000, but the timeout was reported after ~230s. This may be a separate timeout enforcement issue, or a symptom of the same plugin/model registry path blocking before the timeout is applied effectively.
4. Discord shows the same pattern after being enabled
After disabling active-memory again, Discord was enabled with Telegram and ACPX still enabled. Discord's runtime deps were already present in multiple locations (/home/node/.openclaw/node_modules, /app/node_modules, /app/dist/extensions/discord/node_modules, and the mirrored runtime-deps tree).
Gateway restart/load path again showed the smaller active plugin set and reached ready:
2026-04-25T14:28:46.998+10:00 [plugins] acpx installed bundled runtime deps: [email protected]
2026-04-25T14:28:51.706+10:00 [plugins] browser installed bundled runtime deps: @modelcontextprotocol/[email protected], commander@^14.0.3, express@^5.2.1, [email protected], [email protected], [email protected], ws@^8.20.0
2026-04-25T14:28:56.446+10:00 [plugins] discord installed bundled runtime deps: @buape/[email protected], @discordjs/voice@^0.19.2, discord-api-types@^0.38.47, https-proxy-agent@^9.0.0, opusscript@^0.0.8, [email protected], [email protected], ws@^8.20.0
2026-04-25T14:29:02.804+10:00 [plugins] memory-core installed bundled runtime deps: chokidar@^5.0.0, [email protected]
2026-04-25T14:29:07.535+10:00 [plugins] telegram installed bundled runtime deps: @grammyjs/runner@^2.0.3, @grammyjs/transformer-throttler@^1.2.1, grammy@^1.42.0, [email protected], [email protected]
2026-04-25T14:29:08.701+10:00 [gateway] ready (5 plugins: acpx, browser, discord, memory-core, telegram; 27.8s)
2026-04-25T14:33:05.455+10:00 discord channels resolved: 1492067188633243781 (guild:Clawd; aliases:guild:1492067188633243781)
2026-04-25T14:33:06.797+10:00 discord client initialized as 1492070782170431548 (Clawd); awaiting gateway readiness
A first Discord message then triggered the same full provider/plugin runtime-deps pass before the response arrived. The Discord typing indicator reached its 2 minute TTL before the response completed:
2026-04-25T14:36:11.341+10:00 [plugins] acpx installed bundled runtime deps: [email protected]
2026-04-25T14:36:15.876+10:00 [plugins] anthropic installed bundled runtime deps: @mariozechner/[email protected]
2026-04-25T14:36:20.852+10:00 [plugins] brave installed bundled runtime deps: [email protected]
2026-04-25T14:36:25.427+10:00 [plugins] browser installed bundled runtime deps: @modelcontextprotocol/[email protected], commander@^14.0.3, express@^5.2.1, [email protected], [email protected], [email protected], ws@^8.20.0
2026-04-25T14:36:30.098+10:00 [plugins] discord installed bundled runtime deps: @buape/[email protected], @discordjs/voice@^0.19.2, discord-api-types@^0.38.47, https-proxy-agent@^9.0.0, opusscript@^0.0.8, [email protected], [email protected], ws@^8.20.0
2026-04-25T14:36:35.870+10:00 [plugins] google installed bundled runtime deps: @google/genai@^1.50.1, @mariozechner/[email protected]
2026-04-25T14:36:40.466+10:00 [plugins] memory-core installed bundled runtime deps: chokidar@^5.0.0, [email protected]
2026-04-25T14:36:45.149+10:00 [plugins] openai installed bundled runtime deps: @mariozechner/[email protected], ws@^8.20.0
2026-04-25T14:36:50.015+10:00 [plugins] tavily installed bundled runtime deps: [email protected]
2026-04-25T14:36:54.599+10:00 [plugins] telegram installed bundled runtime deps: @grammyjs/runner@^2.0.3, @grammyjs/transformer-throttler@^1.2.1, grammy@^1.42.0, [email protected], [email protected]
2026-04-25T14:37:58.371+10:00 [diagnostic] stuck session: sessionId=unknown sessionKey=agent:main:discord:channel:1492067196031991921 state=processing age=139s queueDepth=1
2026-04-25T14:37:58.378+10:00 [ws] ⇄ res ✓ node.list 62350ms ...
2026-04-25T14:38:26.785+10:00 typing TTL reached (2m); stopping typing indicator
This reinforces that the issue affects channel-triggered turns too, not only web/control-ui turns. Discord itself appears able to initialize, but the first Discord message pays the same repeated runtime-deps/plugin-registry cost.
5. doctor --fix reports missing, installed, then missing again
openclaw doctor --fix reports missing bundled runtime deps, then reports them installed, then reports them missing again in the same run:
Bundled plugin runtime deps are missing.
...
Installed bundled plugin deps: ...
...
Bundled plugin runtime deps are missing.
...
Installed bundled plugin deps: ...
This remains confusing even if some installs succeed, because the post-fix scan still appears unable to see the installed deps.
6. Transient module-resolution failure was observed
A doctor --fix --non-interactive attempt was terminated, with this failure in output:
failed to load from /app/dist/extensions/codex/index.js:
Error: Cannot find module '/home/node/.openclaw/node_modules/ws/index.js'
At another point, that file did exist later:
/home/node/.openclaw/node_modules/ws/package.json exists
/home/node/.openclaw/node_modules/ws/index.js exists
8.20.0
So this may be a bootstrap/staging/race/path-consistency problem rather than a simple permanent npm install failure.
Local inspection / hypothesis
From inspecting runtime-deps state, dependency files appear in multiple places, including:
/home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.23-.../dist/extensions/node_modules
/home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.23-.../dist/extensions/telegram/node_modules
/home/node/.openclaw/node_modules
/app/node_modules
But the doctor/runtime scanner appears to check different or narrower locations, such as:
/home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.23-.../node_modules
/app/dist/extensions/<plugin>/node_modules
Hypothesis: in a non-writable packaged install, OpenClaw's bundled runtime-deps install/staging path, mirrored runtime root, retained manifest, doctor scan path, NODE_PATH mutation, and plugin import resolution are not using one consistent dependency root.
This may be adjacent to, or an incomplete/regressed case after, #70839 / #70852, which mentions root-owned package installs and loading bundled plugins from a mirrored runtime root instead of mutating the package tree.
Expected behavior
- bundled runtime deps should install into one explicit writable runtime-deps directory
- doctor, plugin loader, mirrored root, module resolution, npm cache handling, and retained manifests should all use the same dependency/cache contract
doctor --fix should not report deps missing immediately after reporting them installed
- plugin loading should not depend on mutating
/app, /app/dist/extensions/..., or a default npm cache path that is not guaranteed writable
- secondary flows such as active-memory and channel-triggered turns such as Discord should not trigger another expensive runtime-deps install pass on every first turn / registry load
- active-memory's configured timeout should be enforced close to the configured value, or the logs should distinguish pre-timeout setup work from the timed operation
Actual behavior
- runtime deps are repeatedly installed/reported across multiple plugin-registry paths
- gateway can become ready, but later user/control/plugin flows repeat the install sequence
doctor --fix reports missing deps after install
- plugin loads failed in restricted/non-root bridge conditions with missing mirrored deps (
typebox) and EACCES on npm cache/state (/home/node/.npm)
- gateway/control requests can be delayed long enough to produce stuck-session diagnostics
- active-memory can trigger another full deps sequence and report timeout after ~230s despite
timeoutMs=15000
- Discord can initialize, but a first Discord message can still spend long enough in the repeated runtime-deps/plugin-registry pass for the typing indicator to hit its 2 minute TTL
OpenClaw version
2026.4.23
Operating system
Debian GNU/Linux 12 (openclaw docker image from GHCR)
Install method
docker using ghcr image deployed to Openshift
Model
gpt-5.5
Provider / routing chain
N/A
Additional provider/model setup details
No response
Logs, screenshots, and evidence
When running OpenClaw 2026.4.23 in OpenShift under a restricted SCC, bundled plugin runtime dependencies are repeatedly reported as installed during gateway startup, CLI/status checks, first user turns, and secondary plugin flows such as active-memory.
The gateway can still become usable, and some affected plugins do work. For example, Telegram works and ACPX can reach embedded acpx runtime backend ready. However, the bundled runtime-deps satisfaction check appears not to persist or resolve consistently across plugin-registry paths. This causes repeated install sequences, long first-turn/control delays, stuck-session diagnostics, and at least one transient module-resolution failure.
A fresh Podman run with the default image/user appears much healthier. However, a Podman bridge test using a non-root arbitrary UID and writable /home/node/.openclaw reproduces the same class of problem: /app is not writable, bundled runtime deps cannot be installed/resolved cleanly, and bundled plugins fail or are disabled. The issue seems tied to production-like/container-restricted environments where the packaged application tree (/app) is readable but not writable.
Environment
OpenClaw: 2026.4.23
Runtime: OpenShift / Kubernetes
Security context: restricted SCC-style environment
Packaged app path: /app
/app is readable but not writable by the runtime user
Persistent state/home under /home/node/.openclaw
npm user-level prefix configured to /home/node/.openclaw so global/user installs do not target an immutable packaged application path
Current relevant plugin state during later OpenShift tests:
acpx: enabled
active-memory: disabled again after timeout/noise testing
telegram: enabled and working
discord: enabled and able to initialize
Packaged filesystem contrast
In a fresh Podman container, /app is writable by the runtime user:
node@container:/app$ touch stuff
node@container:/app$ ls
dist docs extensions node_modules openclaw.mjs package.json qa skills stuff
In the OpenShift pod, /app is not writable:
$ pwd
/app
$ touch stuff
touch: cannot touch 'stuff': Permission denied
This distinction matters because production/container deployments commonly treat the packaged app tree as immutable. Runtime scratch/cache writes are fine when they go to explicit writable locations (/tmp, configured cache/state dirs, mounted volumes), but bundled plugin loading should not depend on mutating /app, /app/dist/extensions/..., or npm-global package directories.
This is also why the OpenShift deployment configures npm's prefix under /home/node/.openclaw: in a restricted container, npm global/user installs need to land in persistent writable state rather than the packaged application tree. That should make dynamic installs safer, but it may expose places where OpenClaw's own bundled runtime-deps staging, npm cache handling, and npm's configured prefix are not using the same path contract.
A Podman bridge test can reproduce the filesystem condition without OpenShift. Running the image as a non-root arbitrary UID with a writable .openclaw volume gives the expected permissions:
$ touch /app/stuff
touch: cannot touch '/app/stuff': Permission denied
$ touch /home/node/.openclaw/stuff
# succeeds
Starting the gateway in that setup with --allow-unconfigured then fails bundled plugin runtime-dep installation due to npm cache/state permissions and leaves bundled plugins disabled:
05:03:44 [gateway] starting...
05:04:02 [plugins] 2 plugin(s) failed to initialize (validation: acpx, browser). Run 'openclaw plugins list' for details.
05:04:02 [gateway] [plugins] failed to install bundled runtime deps: Error: npm error code EACCES
npm error syscall mkdir
npm error path /home/node/.npm
npm error errno EACCES
npm error Your cache folder contains root-owned files...
... (plugin=acpx, source=/app/dist/extensions/acpx/index.js)
05:04:02 [gateway] [plugins] failed to install bundled runtime deps: Error: npm error code EACCES
npm error syscall mkdir
npm error path /home/node/.npm
npm error errno EACCES
... (plugin=browser, source=/app/dist/extensions/browser/index.js)
05:04:03 [gateway] ready (3 plugins: device-pair, phone-control, talk-voice; 19.2s)
A separate CLI/plugin load in the same bridge setup also failed to resolve a bundled runtime dependency from the mirrored runtime root:
[plugins] memory-core failed to load from /app/dist/extensions/memory-core/index.js: Error: Cannot find module 'typebox'
Require stack:
- /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.23-f53b52ad6d21/dist/extensions/memory-core/index.js
Setting npm cache and prefix explicitly to writable .openclaw paths avoids the immediate npm EACCES install failure in the Podman bridge test:
export npm_config_cache=/home/node/.openclaw/npm-cache
export NPM_CONFIG_CACHE=/home/node/.openclaw/npm-cache
export npm_config_prefix=/home/node/.openclaw
export NPM_CONFIG_PREFIX=/home/node/.openclaw
mkdir -p /home/node/.openclaw/npm-cache /home/node/.openclaw/lib /home/node/.openclaw/bin
node /app/openclaw.mjs gateway --port 18789 --allow-unconfigured
With those env vars set, bundled runtime-dep installs got past the previous /home/node/.npm permission error and the gateway reached ready, although startup was slower than the default Podman case:
05:13:34 [gateway] starting...
05:13:53 [plugins] acpx installed bundled runtime deps: [email protected]
05:14:34 [plugins] browser installed bundled runtime deps: @modelcontextprotocol/[email protected], express@^5.2.1, [email protected], [email protected], [email protected], ws@^8.20.0
05:14:56 [gateway] ready (5 plugins: acpx, browser, device-pair, phone-control, talk-voice; 81.8s)
05:14:56 [plugins] embedded acpx runtime backend registered (cwd: /home/node/.openclaw/workspace)
05:15:14 [plugins] embedded acpx runtime backend probe failed: embedded ACP runtime probe failed (agent=codex; command=npx @zed-industries/codex-acp@^0.11.1; cwd=/home/node/.openclaw/workspace; ACP agent exited before initialize completed (exit=1, signal=null): WARNING: proceeding, even though we could not update PATH: Permission denied (os error 13) Error: error loading config: Permission denied (os error 13))
After stopping the gateway, node /app/openclaw.mjs plugins list in the same shell loaded 59/102 plugins and showed core bundled/provider plugins loaded, including acpx, browser, memory-core, codex, and many model providers. That suggests the explicit npm cache/prefix env fixed the immediate bundled-dep install failure in the Podman bridge. The remaining ACPX backend probe error appears to be a separate restricted-home/config/PATH permission issue in the nested npx @zed-industries/codex-acp path.
This suggests there are at least two separable concerns:
OpenClaw should set or respect writable npm cache/prefix locations for dynamic runtime-dep installs in restricted containers.
Even after deps are installable, OpenClaw still needs one consistent contract for where bundled runtime deps are installed, scanned, mirrored, retained, and resolved.
ACPX/coding-agent nested runtime setup may need its own restricted-container writable-home/config/PATH handling.
Impact and severity
Affected: all channels
Severity: sever performance degredation
Frequency: every restart
Consquence:
Additional information
Reproduction coverage so far
The following cases have already been exercised:
- Fresh Podman default image/user —
/app is writable; only browser runtime deps installed once; gateway reached ready in ~28.5s.
- Podman bridge with arbitrary non-root UID and writable
.openclaw volume — /app is not writable while /home/node/.openclaw is writable; reproduced bundled runtime-dep install failure when npm cache/default state pointed at unwritable /home/node/.npm.
- Same Podman bridge with npm cache/prefix forced under writable
.openclaw — immediate npm EACCES was resolved and bundled deps installed; gateway reached ready in ~81.8s; ACPX then exposed a separate nested npx/config/PATH permission issue.
- OpenShift restricted SCC deployment — reproduced repeated runtime-deps install/reporting across gateway restart, first web/control turn, active-memory secondary flow, and Discord channel-triggered turn.
Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
OpenClaw expects writable /app in containers, which is often not the case in production-grade Kubernetes environments. Observed under OpenShift restricted SCC, and likely relevant to Kubernetes/container deployments that run as non-root, treat the packaged app tree as immutable, use read-only roots, or restrict writable state/cache paths. With
Steps to reproduce
Environment
2026.4.23/app/appis readable but not writable by the runtime user/home/node/.openclaw/home/node/.openclawso global/user installs do not target an immutable packaged application pathacpx: enabledactive-memory: disabled again after timeout/noise testingtelegram: enabled and workingdiscord: enabled and able to initializePackaged filesystem contrast
In a fresh Podman container,
/appis writable by the runtime user:In the OpenShift pod,
/appis not writable:This distinction matters because production/container deployments commonly treat the packaged app tree as immutable. Runtime scratch/cache writes are fine when they go to explicit writable locations (
/tmp, configured cache/state dirs, mounted volumes), but bundled plugin loading should not depend on mutating/app,/app/dist/extensions/..., or npm-global package directories.This is also why the OpenShift deployment configures npm's prefix under
/home/node/.openclaw: in a restricted container, npm global/user installs need to land in persistent writable state rather than the packaged application tree. That should make dynamic installs safer, but it may expose places where OpenClaw's own bundled runtime-deps staging, npm cache handling, and npm's configured prefix are not using the same path contract.A Podman bridge test can reproduce the filesystem condition without OpenShift. Running the image as a non-root arbitrary UID with a writable
.openclawvolume gives the expected permissions:Starting the gateway in that setup with
--allow-unconfiguredthen fails bundled plugin runtime-dep installation due to npm cache/state permissions and leaves bundled plugins disabled:A separate CLI/plugin load in the same bridge setup also failed to resolve a bundled runtime dependency from the mirrored runtime root:
Setting npm cache and prefix explicitly to writable
.openclawpaths avoids the immediate npmEACCESinstall failure in the Podman bridge test:With those env vars set, bundled runtime-dep installs got past the previous
/home/node/.npmpermission error and the gateway reached ready, although startup was slower than the default Podman case:After stopping the gateway,
node /app/openclaw.mjs plugins listin the same shell loaded 59/102 plugins and showed core bundled/provider plugins loaded, includingacpx,browser,memory-core,codex, and many model providers. That suggests the explicit npm cache/prefix env fixed the immediate bundled-dep install failure in the Podman bridge. The remaining ACPX backend probe error appears to be a separate restricted-home/config/PATH permission issue in the nestednpx @zed-industries/codex-acppath.This suggests there are at least two separable concerns:
Observed behavior
1. Repeated runtime-deps install sequence
During startup / CLI / user-turn paths in OpenShift, multiple bundled plugins repeatedly report runtime dependency installs:
This includes plugins/providers from both packaged/bundled paths and dynamically configured state. The issue does not appear limited to one plugin origin.
2. Gateway can become ready, but later paths repeat the install sequence
After re-enabling ACPX alone, the gateway restarted cleanly and ACPX reached ready:
However, the first subsequent user turn triggered another full bundled runtime-deps sequence before the agent could begin responding. This took about two minutes from user request to first assistant turn and ended with a stuck-session warning plus delayed
node.list:This suggests ACPX itself can load, but bundled runtime deps are not recognized as already satisfied across later plugin-registry/session-control paths.
3. Multiple plugin-registry passes appear to occur
With
acpxandactive-memoryenabled, there appear to be multiple distinct plugin-registry/runtime-deps passes:acpx,browser,memory-core,telegram), then gateway ready.acpx,anthropic,brave,browser,google,memory-core,openai,tavily,telegram), then delayed control responses.Example restart/load path:
Example first-turn/control path after that restart:
Example active-memory path:
The active-memory config had
timeoutMs=15000, but the timeout was reported after ~230s. This may be a separate timeout enforcement issue, or a symptom of the same plugin/model registry path blocking before the timeout is applied effectively.4. Discord shows the same pattern after being enabled
After disabling active-memory again, Discord was enabled with Telegram and ACPX still enabled. Discord's runtime deps were already present in multiple locations (
/home/node/.openclaw/node_modules,/app/node_modules,/app/dist/extensions/discord/node_modules, and the mirrored runtime-deps tree).Gateway restart/load path again showed the smaller active plugin set and reached ready:
A first Discord message then triggered the same full provider/plugin runtime-deps pass before the response arrived. The Discord typing indicator reached its 2 minute TTL before the response completed:
This reinforces that the issue affects channel-triggered turns too, not only web/control-ui turns. Discord itself appears able to initialize, but the first Discord message pays the same repeated runtime-deps/plugin-registry cost.
5.
doctor --fixreports missing, installed, then missing againopenclaw doctor --fixreports missing bundled runtime deps, then reports them installed, then reports them missing again in the same run:This remains confusing even if some installs succeed, because the post-fix scan still appears unable to see the installed deps.
6. Transient module-resolution failure was observed
A
doctor --fix --non-interactiveattempt was terminated, with this failure in output:At another point, that file did exist later:
So this may be a bootstrap/staging/race/path-consistency problem rather than a simple permanent npm install failure.
Local inspection / hypothesis
From inspecting runtime-deps state, dependency files appear in multiple places, including:
But the doctor/runtime scanner appears to check different or narrower locations, such as:
Hypothesis: in a non-writable packaged install, OpenClaw's bundled runtime-deps install/staging path, mirrored runtime root, retained manifest, doctor scan path,
NODE_PATHmutation, and plugin import resolution are not using one consistent dependency root.This may be adjacent to, or an incomplete/regressed case after, #70839 / #70852, which mentions root-owned package installs and loading bundled plugins from a mirrored runtime root instead of mutating the package tree.
Expected behavior
doctor --fixshould not report deps missing immediately after reporting them installed/app,/app/dist/extensions/..., or a default npm cache path that is not guaranteed writableActual behavior
doctor --fixreports missing deps after installtypebox) and EACCES on npm cache/state (/home/node/.npm)timeoutMs=15000OpenClaw version
2026.4.23
Operating system
Debian GNU/Linux 12 (openclaw docker image from GHCR)
Install method
docker using ghcr image deployed to Openshift
Model
gpt-5.5
Provider / routing chain
N/A
Additional provider/model setup details
No response
Logs, screenshots, and evidence
Impact and severity
Affected: all channels
Severity: sever performance degredation
Frequency: every restart
Consquence:
Additional information
Reproduction coverage so far
The following cases have already been exercised:
/appis writable; only browser runtime deps installed once; gateway reached ready in ~28.5s..openclawvolume —/appis not writable while/home/node/.openclawis writable; reproduced bundled runtime-dep install failure when npm cache/default state pointed at unwritable/home/node/.npm..openclaw— immediate npmEACCESwas resolved and bundled deps installed; gateway reached ready in ~81.8s; ACPX then exposed a separate nestednpx/config/PATH permission issue.