[gateway] starting... | Friends of the Crustacean 🦞🤝 | Page 1

warm granite Apr 28, 2026, 10:47 PM

#

logs = " 2026-04-29 05:41:44,358 INFO success: openclaw-gateway entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2026-04-29 05:41:44,358 INFO success: typhoon-api entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2026-04-29 05:41:44,358 INFO success: zai-quota-monitor entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

│

◇ Config warnings ──────────────────────────────────────────────────────╮

│ │

│ - plugins: plugin: ignored plugins.load.paths entry that points at │

│ OpenClaw's current bundled plugin directory; remove this redundant │

│ path or run openclaw doctor --fix │

│ │

├────────────────────────────────────────────────────────────────────────╯

2026-04-29T05:41:48.460+07:00 [gateway] loading configuration…

2026-04-29T05:41:48.559+07:00 [gateway] resolving authentication…

2026-04-29T05:41:48.565+07:00 [gateway] starting... " on docker container i use old patch settings and workspace, do i need to update config or something ?

pliant cosmosBOT Apr 28, 2026, 10:47 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

sage helmBOT Apr 28, 2026, 10:50 PM

#

Short answer: yes, clean up/migrate the config; probably not the workspace. That warning is usually from an old plugins.load.paths entry pointing at OpenClaw’s bundled plugin dir. It’s ignored and usually not fatal, but it’s stale config. plugins.load.paths should be for extra/custom plugin paths only. (docs.openclaw.ai)

Please paste your version/image tag first:

docker compose run --rm openclaw-cli --version

Then I’d do:

docker compose run --rm openclaw-cli config get plugins.load.paths --json
docker compose run --rm openclaw-cli doctor --fix
docker compose restart openclaw-gateway
curl -fsS http://127.0.0.1:18789/readyz

#

Docker’s mounted config/state lives under /home/node/.openclaw, so run doctor --fix through the same compose setup/volume you actually use. The Docker docs also recommend /readyz for readiness checks. (docs.openclaw.ai)

If it still sits at [gateway] starting..., paste:

docker compose logs --tail=200 openclaw-gateway
docker compose run --rm openclaw-cli status --all

warm granite Apr 28, 2026, 11:02 PM

#

I'm on OpenClaw 2026.4.26 , and doctor fix stuck on this for 10 mins , logs exec = docker compose --env-file .env.chunny_1 exec openclaw-gateway openclaw doctor --fix
Config warnings:

plugins: plugin: ignored plugins.load.paths entry that points at OpenClaw's current bundled plugin directory; remove this redundant path or run openclaw doctor --fix

🦞 OpenClaw 2026.4.26 (unknown) — The only crab in your contacts you actually want to hear from. 🦞

              🦞 OPENCLAW 🦞

┌ OpenClaw doctor
│
◇ Startup optimization ─────────────────────────────────────────────────────────────────────╮
│ │
│ - NODE_COMPILE_CACHE is not set; repeated CLI runs can be slower on small hosts (Pi/VM). │
│ - OPENCLAW_NO_RESPAWN is not set to 1; set it to avoid extra startup overhead from │
│ self-respawn. │
│ - Suggested env for low-power hosts: │
│ export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache │
│ mkdir -p /var/tmp/openclaw-compile-cache │
│ export OPENCLAW_NO_RESPAWN=1 │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
│
◇ Config warnings ───────────────────────────────────────────────────────────────────────╮
│ │
│ - plugins: plugin: ignored plugins.load.paths entry that points at OpenClaw's current │
│ bundled plugin directory; remove this redundant path or run openclaw doctor --fix │

sage helmBOT Apr 28, 2026, 11:03 PM

#

Yep — this looks like stale plugin config from the old patched setup, not a workspace problem.

The warning specifically means plugins.load.paths contains a path that points back at OpenClaw’s own bundled plugins. That path is now redundant/ignored; plugins.load.paths should only be for custom/external plugin dirs.

If doctor --fix has been stuck 10 min, stop it and try non-interactive repair:

docker compose --env-file .env.chunny_1 exec -T \
  -e OPENCLAW_NO_RESPAWN=1 \
  -e NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache \
  openclaw-gateway sh -lc 'mkdir -p /var/tmp/openclaw-compile-cache && openclaw doctor --repair --yes'

If that still hangs, inspect the stale value:

#

docker compose --env-file .env.chunny_1 exec openclaw-gateway \
  openclaw config get plugins.load.paths --json

If it only contains OpenClaw bundled paths like /app/dist/extensions, /app/extensions, or a global .../openclaw/.../extensions path, you can remove the whole key:

docker compose --env-file .env.chunny_1 exec openclaw-gateway \
  openclaw config unset plugins.load.paths

docker compose --env-file .env.chunny_1 restart openclaw-gateway

If it has your own custom plugin paths too, don’t unset the whole thing — edit ~/.openclaw/openclaw.json and remove only the bundled OpenClaw path.

The startup optimization warnings are just performance tips, not the blocker. After restart, check:

#

docker compose --env-file .env.chunny_1 exec openclaw-gateway \
  curl -fsS http://127.0.0.1:18789/readyz

Docs: https://docs.openclaw.ai/gateway/doctor and https://docs.openclaw.ai/tools/plugin

warm granite Apr 28, 2026, 11:08 PM

#

docker compose --env-file .env.chunny_1 exec -T openclaw-gateway openclaw config get plugins.load.paths --json
Config path not found: plugins.load.paths

sage helmBOT Apr 28, 2026, 11:08 PM

#

Nice, that’s useful: plugins.load.paths is already gone from the config you’re reading. So don’t keep chasing that warning yet — it may be from the earlier doctor --fix run/output, or from a different config path/container.

Next step: restart and re-check fresh logs.

docker compose --env-file .env.chunny_1 restart openclaw-gateway
docker compose --env-file .env.chunny_1 logs --tail=200 openclaw-gateway

Then check readiness:

docker compose --env-file .env.chunny_1 exec -T openclaw-gateway curl -fsS http://127.0.0.1:18789/readyz

If it still hangs at [gateway] starting..., run:

#

docker compose --env-file .env.chunny_1 exec -T openclaw-gateway openclaw status --all
docker compose --env-file .env.chunny_1 exec -T openclaw-gateway openclaw gateway status --json

At this point the plugin warning is probably not the blocker. The docs say plugins.load.paths is only for extra plugin dirs, and bundled-path entries are ignored; config changes need gateway restart. For Docker, /readyz is the right readiness check. (docs.openclaw.ai)

If the warning comes back after restart while config get plugins.load.paths still says path not found, that’s likely worth a GitHub issue with the exact compose/env setup: https://github.com/openclaw/openclaw/issues

OpenClaw

Plugins - OpenClaw

#

Yep — that confirms the config path you’re querying does not have that stale key anymore.

So now we need to tell whether the warning is just old log output or the gateway is using a different config path. Run these:

docker compose --env-file .env.chunny_1 restart openclaw-gateway
docker compose --env-file .env.chunny_1 logs --since=2m openclaw-gateway

If the warning still appears in fresh logs, check what config path/env the container is actually using:

docker compose --env-file .env.chunny_1 exec -T openclaw-gateway sh -lc 'echo HOME=$HOME; echo OPENCLAW_CONFIG_PATH=${OPENCLAW_CONFIG_PATH:-unset}; ls -la ~/.openclaw'

And get the diagnostic bundle:

#

docker compose --env-file .env.chunny_1 exec -T openclaw-gateway openclaw status --all

If fresh logs don’t show the warning anymore, you’re good — the earlier warning was just stale output. The remaining [gateway] starting... needs the fresh logs --since=2m / status --all output to see the real blocker.

warm granite Apr 28, 2026, 11:14 PM

#

o
openclaw-gateway | │ │
openclaw-gateway | ├────────────────────────────────────────────────────────────────────────╯
openclaw-gateway | 2026-04-29T06:09:56.103+07:00 [gateway] loading configuration…
openclaw-gateway | 2026-04-29T06:09:56.204+07:00 [gateway] resolving authentication…
openclaw-gateway | 2026-04-29T06:09:56.210+07:00 [gateway] starting...
openclaw-gateway | 2026-04-29T06:10:04.857+07:00 [gateway] starting HTTP server...
openclaw-gateway | 2026-04-29T06:10:04.867+07:00 [canvas] host mounted at http://0.0.0.0:19789/__openclaw__/canvas/ (root /home/node/.openclaw/canvas)
openclaw-gateway | 2026-04-29T06:10:04.873+07:00 [gateway] ⚠️ Gateway is binding to a non-loopback address. Ensure authentication is configured before exposing to public networks.
openclaw-gateway | 2026-04-29T06:10:04.885+07:00 [tasks/registry] Failed to restore task registry
openclaw-gateway | 2026-04-29T06:10:05.036+07:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
openclaw-gateway | 2026-04-29T06:10:05.183+07:00 [gateway] agent model: zai/glm-5-turbo
openclaw-gateway | 2026-04-29T06:10:05.188+07:00 [gateway] http server listening (10 plugins: acpx, bonjour, browser, device-pair, discord, memory-core, memory-wiki, phone-control, talk-voice, telegram; 9.0s)
openclaw-gateway | 2026-04-29T06:10:05.193+07:00 [gateway] log file: /tmp/openclaw/openclaw-2026-04-29.log
openclaw-gateway | 2026-04-29T06:10:05.211+07:00 [gateway] security warning: dangerous config flags enabled: plugins.entries.acpx.config.permissionMode=approve-all. Run openclaw security audit.
openclaw-gateway | 2026-04-29T06:10:05.218+07:00 [gateway] starting channels and sidecars...

sage helmBOT Apr 28, 2026, 11:14 PM

#

Good news: this is not stuck at [gateway] starting... anymore — it reached:

[gateway] http server listening ... (9.0s)
[gateway] starting channels and sidecars...

So the stale plugin warning is likely not the blocker now.

Check if the gateway is actually ready:

docker compose --env-file .env.chunny_1 exec -T openclaw-gateway curl -fsS http://127.0.0.1:18789/readyz
docker compose --env-file .env.chunny_1 exec -T openclaw-gateway openclaw status --all
docker compose --env-file .env.chunny_1 exec -T openclaw-gateway openclaw channels status --probe

#

If it hangs after starting channels and sidecars..., it’s probably one channel/plugin sidecar blocking startup — Discord/Telegram/browser/etc. The channels status --probe output should tell us which one.

Two important warnings in your log:

Failed to restore task registry — may be recoverable, but paste the nearby lines from the log file if issues continue:

docker compose --env-file .env.chunny_1 exec -T openclaw-gateway tail -n 120 /tmp/openclaw/openclaw-2026-04-29.log

permissionMode=approve-all is dangerous, especially since gateway binds to non-loopback. Run:

docker compose --env-file .env.chunny_1 exec -T openclaw-gateway openclaw security audit

Docs: https://docs.openclaw.ai/gateway/troubleshooting and https://docs.openclaw.ai/install/docker

warm granite Apr 28, 2026, 11:15 PM

#

2026-04-29T06:11:52.647+07:00 [plugins] plugin service failed (acpx-runtime, plugin=acpx, root=/app/dist/extensions/acpx): EPERM: operation not permitted, chmod '/home/node/.openclaw/acpx/codex-acp-wrapper.mjs'

Error: EPERM: operation not permitted, chmod '/home/node/.openclaw/acpx/codex-acp-wrapper.mjs'

at async Object.chmod (node:internal/fs/promises:1077:10)

at async writeCodexAcpWrapper (file:///home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/dist/extensions/acpx/register.runtime-CfTvMCxA.js:92:2)

at async prepareAcpxCodexAuthConfig (file:///home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/dist/extensions/acpx/register.runtime-CfTvMCxA.js:104:22)

at async Object.start (file:///home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/dist/extensions/acpx/register.runtime-CfTvMCxA.js:724:25)

at async startPluginServices (file:///app/dist/services-DLMYTZsi.js:37:4)

at async file:///app/dist/server.impl-hNr66nDN.js:8578:21

at async Object.measure (file:///app/dist/server.impl-hNr66nDN.js:10685:12)

at async Object.startGatewaySidecars (file:///app/dist/server.impl-hNr66nDN.js:8575:2)

at async Object.measure (file:///app/dist/server.impl-hNr66nDN.js:10685:12)

at async file:///app/dist/server.impl-hNr66nDN.js:8672:18

sage helmBOT Apr 28, 2026, 11:15 PM

#

Aha, that’s the real blocker:

EPERM: operation not permitted, chmod '/home/node/.openclaw/acpx/codex-acp-wrapper.mjs'

This is the acpx/Codex ACP plugin, not the old plugins.load.paths warning. Since you’re on Windows/Docker (D:\...), this is very likely a bind-mount/permission issue: OpenClaw is trying to chmod a wrapper file inside /home/node/.openclaw, but the mounted filesystem won’t allow Unix chmod.

Quick workaround if you’re not actively using Codex/ACP:

docker compose --env-file .env.chunny_1 exec -T openclaw-gateway openclaw config set plugins.entries.acpx.enabled false
docker compose --env-file .env.chunny_1 restart openclaw-gateway

Then check:

#

docker compose --env-file .env.chunny_1 exec -T openclaw-gateway curl -fsS http://127.0.0.1:18789/readyz

Also: you currently have plugins.entries.acpx.config.permissionMode=approve-all, and the gateway is binding non-loopback. That’s risky — disabling acpx is the safest immediate move.

If you do need ACP/Codex, the better fix is to put /home/node/.openclaw on a Linux-native Docker volume / WSL filesystem, not a Windows D:\... bind mount, so chmod works properly. Docs: https://docs.openclaw.ai/install/docker

warm granite Apr 28, 2026, 11:18 PM

#

what about this one = 2026-04-29T06:13:07.135+07:00 [telegram] deleteWebhook failed: Network request for 'deleteWebhook' failed!

2026-04-29T06:13:07.143+07:00 [telegram] webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 2.29s.

sage helmBOT Apr 28, 2026, 11:18 PM

#

That one is Telegram networking, separate from the ACP chmod issue.

OpenClaw Telegram uses long polling by default, and on startup it tries to clean up any old webhook with Telegram’s API. This log means the container couldn’t reach Telegram’s API endpoint for deleteWebhook:

Network request for 'deleteWebhook' failed

Most likely causes: DNS, proxy, IPv6 routing, firewall, or Telegram blocked/unreachable from that host/container.

Test from inside the container:

docker compose --env-file .env.chunny_1 exec -T openclaw-gateway sh -lc 'node -e "fetch(\"https://api.telegram.org\").then(r=>console.log(r.status)).catch(e=>console.error(e))"'

Also check channel status:

#

docker compose --env-file .env.chunny_1 exec -T openclaw-gateway openclaw channels status --probe

If the fetch fails, fix container network/proxy/DNS first. If you use a proxy, make sure the gateway container actually has HTTPS_PROXY / HTTP_PROXY env set, and don’t accidentally bypass Telegram with NO_PROXY.

Docs call out Telegram “send failures with network errors” as DNS/IPv6/proxy routing to api.telegram.org: https://docs.openclaw.ai/channels/troubleshooting

warm granite Apr 29, 2026, 10:12 AM

#

help me fix plugin.load.paths from this log : 2026-04-29T17:10:35.148+07:00 [plugins] plugin service failed (acpx-runtime, plugin=acpx, root=/app/dist/extensions/acpx): EPERM: operation not permitted, chmod '/home/node/.openclaw/acpx/codex-acp-wrapper.mjs'

Error: EPERM: operation not permitted, chmod '/home/node/.openclaw/acpx/codex-acp-wrapper.mjs'

at async Object.chmod (node:internal/fs/promises:1077:10)

at async writeCodexAcpWrapper (file:///home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/dist/extensions/acpx/register.runtime-CfTvMCxA.js:92:2)

at async prepareAcpxCodexAuthConfig (file:///home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/dist/extensions/acpx/register.runtime-CfTvMCxA.js:104:22)

at async Object.start (file:///home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/dist/extensions/acpx/register.runtime-CfTvMCxA.js:724:25)

at async startPluginServices (file:///app/dist/services-DLMYTZsi.js:37:4)

at async file:///app/dist/server.impl-hNr66nDN.js:8578:21

at async Object.measure (file:///app/dist/server.impl-hNr66nDN.js:10685:12)

at async Object.startGatewaySidecars (file:///app/dist/server.impl-hNr66nDN.js:8575:2)

at async Object.measure (file:///app/dist/server.impl-hNr66nDN.js:10685:12)

at async file:///app/dist/server.impl-hNr66nDN.js:8672:18

sage helmBOT Apr 29, 2026, 10:13 AM

#

Your log shows OpenClaw 2026.4.26 in the runtime path — first please confirm:

openclaw --version

Two separate things are happening:

plugins.load.paths warning
That stale bundled plugin path can usually be cleaned with:

openclaw doctor --fix

Then restart the gateway/container.

#

Docs: https://docs.openclaw.ai/tools/plugin

Actual crash: EPERM chmod '/home/node/.openclaw/acpx/codex-acp-wrapper.mjs'
This is more likely a Docker volume permission/ownership issue, not plugins.load.paths. The container’s node user can write/read that file path badly or can’t chmod it.

If using Docker Compose, try:

docker compose exec -u root <service-name> sh -lc 'chown -R node:node /home/node/.openclaw'
docker compose restart <service-name>

If /home/node/.openclaw is a bind mount from Windows/NTFS/CIFS/NFS or another filesystem that rejects chmod, move it to a Docker named volume or Linux/ext4-backed path.

Also: since current source treats that wrapper chmod as best-effort, updating off 2026.4.26 may help too after fixing permissions. Then run:

#

openclaw doctor
/acp doctor

warm granite Apr 29, 2026, 10:27 AM

#

still : 2026-04-29T17:26:06.891+07:00 [channels] failed to load bundled channel line: Timed out waiting for bundled runtime deps lock at /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/.openclaw-runtime-mirror.lock (waited=300047ms, ownerFile=ok, ownerFileSymlink=false, pid=9 alive=true, ownerAge=375124ms, ownerFileAge=375127ms, lockAge=375127ms, ownerFilePath=/home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/.openclaw-runtime-mirror.lock/owner.json). If no OpenClaw/npm install is running, remove the lock directory and retry. | EEXIST: file already exists, mkdir '/home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/.openclaw-runtime-mirror.lock' ◇ Config warnings ──────────────────────────────────────────────────────╮

│ │

│ - plugins: plugin: ignored plugins.load.paths entry that points at │

│ OpenClaw's current bundled plugin directory; remove this redundant │

│ path or run openclaw doctor --fix │

│ │

├───────────

sage helmBOT Apr 29, 2026, 10:28 AM

#

That one is not the plugins.load.paths warning anymore — it’s a stuck bundled runtime-deps lock.

The important bit is:

pid=9 alive=true ... If no OpenClaw/npm install is running, remove the lock directory and retry

Because pid=9 is still alive, stop the gateway/container first, then remove only that exact lock dir.

If using docker compose:

docker compose stop <openclaw-service-name>

docker compose run --rm --user root --entrypoint sh <openclaw-service-name> -lc '

#

rm -rf /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/.openclaw-runtime-mirror.lock
chown -R node:node /home/node/.openclaw
'

docker compose up -d <openclaw-service-name>

Then clean the old plugin path warning:

docker compose exec <openclaw-service-name> openclaw doctor --fix
docker compose restart <openclaw-service-name>

Also, you’re on 2026.4.26 from the path. If you’re using an old Docker image/old patch workspace, I’d update the image after this cleanup — this looks like stale runtime-deps state plus permissions from the old mounted workspace.

#

Docs: https://docs.openclaw.ai/tools/plugin

warm granite Apr 29, 2026, 10:53 AM

#

still : 2026-04-29T17:37:31.109+07:00 [channels] failed to load bundled channel line: Timed out waiting for bundled runtime deps lock at /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/.openclaw-runtime-mirror.lock (waited=300058ms, ownerFile=ok, ownerFileSymlink=false, pid=9 alive=true, ownerAge=307365ms, ownerFileAge=307368ms, lockAge=307368ms, ownerFilePath=/home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/.openclaw-runtime-mirror.lock/owner.json). If no OpenClaw/npm install is running, remove the lock directory and retry. | EEXIST: file already exists, mkdir '/home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/.openclaw-runtime-mirror.lock'

sage helmBOT Apr 29, 2026, 10:53 AM

#

That means something inside the container is still holding the lock — pid=9 alive=true. Don’t remove only the lock while OpenClaw is running; it’ll just come back.

Try clearing the whole generated runtime cache while the container is fully stopped:

docker compose down

docker compose run --rm --user root --entrypoint sh <openclaw-service-name> -lc '
set -eux
rm -rf /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21
mkdir -p /home/node/.openclaw/plugin-runtime-deps
chown -R node:node /home/node/.openclaw
'

docker compose up -d <openclaw-service-name>

#

Important: delete only that plugin-runtime-deps/openclaw-2026.4.26-... folder, not all of /home/node/.openclaw.

If it still happens after that, check what pid 9 is:

docker compose exec <openclaw-service-name> sh -lc 'ps -p 9 -o pid,ppid,user,etime,args'

Also make sure you don’t have two OpenClaw containers sharing the same /home/node/.openclaw volume. That can cause this exact lock fight.

warm granite Apr 29, 2026, 10:59 AM

#

solved : 2026-04-29T17:55:26.154+07:00 [gateway] [plugins] staging bundled runtime deps before gateway startup (19 missing, 21 install specs): @buape/carbon@0.16.0, @discordjs/voice@^0.19.2, @grammyjs/runner@^2.0.3, @grammyjs/transformer-throttler@^1.2.1, @homebridge/ciao@^1.3.6, @modelcontextprotocol/sdk@1.29.0, acpx@0.6.1, chokidar@^5.0.0, commander@^14.0.3, discord-api-types@^0.38.47, express@5.2.1, grammy@^1.42.0, https-proxy-agent@^9.0.0, opusscript@^0.1.1, playwright-core@1.59.1, typebox@1.1.33, undici@8.1.0, ws@^8.20.0, yaml@^2.8.3

2026-04-29T17:55:56.710+07:00 [gateway] [plugins] installed bundled runtime deps before gateway startup in 30556ms: @buape/carbon@0.16.0, @discordjs/voice@^0.19.2, @grammyjs/runner@^2.0.3, @grammyjs/transformer-throttler@^1.2.1, @homebridge/ciao@^1.3.6, @modelcontextprotocol/sdk@1.29.0, acpx@0.6.1, chokidar@^5.0.0, commander@^14.0.3, discord-api-types@^0.38.47, express@5.2.1, grammy@^1.42.0, https-proxy-agent@^9.0.0, opusscript@^0.1.1, playwright-core@1.59.1, typebox@1.1.33, undici@8.1.0, ws@^8.20.0, yaml@^2.8.3 . these fix is temporary or permanent ?

sage helmBOT Apr 29, 2026, 10:59 AM

#

Nice — that log means it rebuilt the missing bundled plugin runtime deps successfully. 🎉

It’s persistent as long as /home/node/.openclaw/plugin-runtime-deps/... is on a persistent Docker volume/bind mount and ownership stays correct.

It can happen again if you:

delete/recreate the Docker volume
change OpenClaw version/image, e.g. 2026.4.26 → newer version
run two containers sharing the same .openclaw volume
mount .openclaw from a filesystem with weird chmod/lock behavior
restore an old workspace/config backup

So: not just temporary, but also not “forever” — it’s a generated cache per OpenClaw build/version. On future upgrades, seeing one clean “staging/installing bundled runtime deps” pass is normal.

I’d still run once:

#

openclaw doctor --fix

to remove the old plugins.load.paths warning, then restart. If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for future users.

warm granite Apr 29, 2026, 11:08 AM

#

how to fix this problem permanent ?

sage helmBOT Apr 29, 2026, 11:09 AM

#

For a permanent fix, move plugin runtime deps out of /home/node/.openclaw and into a dedicated Docker named volume.

Your log shows OpenClaw is using:

/home/node/.openclaw/plugin-runtime-deps/...

For Docker, better permanent setup is:

services:
  openclaw-gateway:
    environment:
      OPENCLAW_PLUGIN_STAGE_DIR: /var/lib/openclaw/plugin-runtime-deps
    volumes:

#

      - openclaw-config:/home/node/.openclaw
      - openclaw-plugin-runtime-deps:/var/lib/openclaw/plugin-runtime-deps

volumes:
  openclaw-config:
  openclaw-plugin-runtime-deps:

If you already bind-mount config from host, keep that, but still add the separate runtime-deps volume:

volumes:
  - ./openclaw-data:/home/node/.openclaw
  - openclaw-plugin-runtime-deps:/var/lib/openclaw/plugin-runtime-deps

#

Then clean once:

docker compose down

docker volume rm <project>_openclaw-plugin-runtime-deps 2>/dev/null || true

docker compose up -d

Also run this once to permanently remove the old bundled plugin path warning:

docker compose exec <service-name> openclaw doctor --fix
docker compose restart <service-name>

#

Checklist to avoid it coming back:

only one OpenClaw gateway container uses the same .openclaw config
don’t store plugin runtime deps on Windows/NTFS/NFS/CIFS bind mounts
keep OPENCLAW_PLUGIN_STAGE_DIR=/var/lib/openclaw/plugin-runtime-deps
keep that path mounted as a Docker named volume
update off old 2026.4.26 when you can

Docs: https://docs.openclaw.ai/install/docker

warm granite Apr 29, 2026, 12:14 PM

#

before closing this case here the summary please copy this and reply to this chat and i will make solve emoji, Thanks for helping me : Fix: OpenClaw Docker EPERM chmod & Stale Plugin Lock on Windows/NTFS
Problem
When running OpenClaw in Docker with /home/node/.openclaw as a bind mount from a Windows host (NTFS), you may encounter these errors:

EPERM: operation not permitted, chmod
The acpx plugin tries to chmod a file inside /home/node/.openclaw/acpx/ but NTFS does not support Unix file permissions, so the operation fails.

Timed out waiting for bundled runtime deps lock
The plugin runtime deps lock file gets stuck because the directory sits on the same NTFS bind mount, causing lock and permission conflicts (EEXIST: file already exists, mkdir).

plugins.load.paths warning
OpenClaw warns about a redundant bundled plugin path entry.

Root Cause
All three issues stem from the same source: plugin runtime dependencies are stored inside /home/node/.openclaw/, which is bind-mounted from a Windows NTFS filesystem. NTFS lacks Unix permission support and handles file locking differently, causing chmod, mkdir, and lock operations to fail.

Permanent Fix
Use OPENCLAW_PLUGIN_STAGE_DIR to move plugin runtime deps to a dedicated path backed by a Docker named volume, which uses the Docker VM's ext4 filesystem instead of NTFS.

In docker-compose.yml, add the environment variable:

OPENCLAW_PLUGIN_STAGE_DIR=/var/lib/openclaw/plugin-runtime-deps

Then in your volumes section, keep your existing config bind mount but add a named volume for the new plugin path:

./data:/home/node/.openclaw
openclaw-plugin-runtime-deps:/var/lib/openclaw/plugin-runtime-deps
And declare the volume at the bottom:

volumes:
openclaw-plugin-runtime-deps:

In your Dockerfile, add this before the USER node line:

RUN mkdir -p /var/lib/openclaw/plugin-runtime-deps && chown -R node:node /home/node/.openclaw /var/lib/openclaw

not finish yet here the part two : ...

#

This pre-creates the directory with correct ownership so the named volume inherits it instead of defaulting to root.

Cleanup and Deploy
First stop everything:

docker compose down

Then remove stale volumes from the old setup:

docker volume rm <project>_plugin-runtime-deps

If it does not exist, that is fine.

Then rebuild if using a local image and start:

docker compose build && docker compose up -d

Why This Works
The config directory (/home/node/.openclaw) stays on the NTFS bind mount since config files do not need chmod. The plugin runtime deps move to /var/lib/openclaw/plugin-runtime-deps on a Docker named volume, which runs on ext4 inside the Docker VM where chmod, mkdir, and file locking all work correctly. The OPENCLAW_PLUGIN_STAGE_DIR environment variable tells OpenClaw to use this new path for all plugin runtime dependency operations, keeping them completely off the NTFS bind mount.

Final Cleanup
After deploying, run these to clear the plugins.load.paths warning:

docker compose exec openclaw-gateway openclaw doctor --fix
docker compose restart openclaw-gateway

sage helmBOT Apr 29, 2026, 12:15 PM

#

Yep — send part two and I’ll merge it into one clean “solution” reply for you.

Tiny note already: I’ll probably adjust the Dockerfile line a bit so it doesn’t depend on the bind mount existing at build time.

#

Fix: OpenClaw Docker EPERM chmod & stale plugin lock on Windows/NTFS

Problem

When running OpenClaw in Docker with /home/node/.openclaw bind-mounted from a Windows/NTFS host, you may see:

EPERM: operation not permitted, chmod

The acpx plugin tries to chmod a generated wrapper under /home/node/.openclaw/acpx/, but NTFS bind mounts do not behave like a normal Linux filesystem for Unix permissions.

You may also see:

Timed out waiting for bundled runtime deps lock

#

EEXIST: file already exists, mkdir ...

because bundled plugin runtime deps and lock files were being created under the same NTFS-backed bind mount.

There was also a separate warning:

plugins.load.paths entry that points at OpenClaw's current bundled plugin directory

That one is stale config and can be cleaned with doctor --fix.

Root cause

Plugin runtime/generated files were stored inside /home/node/.openclaw, which was bind-mounted from Windows/NTFS. NTFS can cause trouble with chmod, mkdir, and lock-directory behavior from inside Linux containers.

#

Permanent fix

Move plugin runtime deps to a Docker named volume using OPENCLAW_PLUGIN_STAGE_DIR.

In docker-compose.yml:

services:
  openclaw-gateway:
    environment:
      OPENCLAW_PLUGIN_STAGE_DIR: /var/lib/openclaw/plugin-runtime-deps
    volumes:
      - ./data:/home/node/.openclaw
      - openclaw-plugin-runtime-deps:/var/lib/openclaw/plugin-runtime-deps

volumes:

#

  openclaw-plugin-runtime-deps:

If using a custom Dockerfile, pre-create the directory before switching to USER node:

RUN mkdir -p /var/lib/openclaw/plugin-runtime-deps \
  && chown -R node:node /var/lib/openclaw

Cleanup and deploy

docker compose down
docker volume rm <project>_openclaw-plugin-runtime-deps 2>/dev/null || true

#

docker compose build
docker compose up -d

If you are not building a local image, skip docker compose build.

Final cleanup

Run once to clear the old plugins.load.paths warning:

docker compose exec openclaw-gateway openclaw doctor --fix
docker compose restart openclaw-gateway

Why this works

#

/home/node/.openclaw can stay as the config bind mount. The generated plugin runtime deps move to /var/lib/openclaw/plugin-runtime-deps, backed by Docker’s Linux filesystem via a named volume, where permissions and lock directories work correctly.

warm granite Apr 29, 2026, 12:18 PM

#

how to mark solution ?

sage helmBOT Apr 29, 2026, 12:18 PM

#

On Discord:

Find the message with the final solution summary.
Right-click that message.
Go to Apps.
Click ✅ Mark Solution.

If you’re on mobile: long-press the message → Apps → ✅ Mark Solution.

Thanks for doing that — it helps Answer Overflow index the fix for the next person. 🦐

#

I just restarted fresh and couldn’t recover much prior context here — no recent resume file showed up, and the highlights file is missing in this workspace.

To mark a solution in this help thread:

Right-click the message that solved your problem
Choose Apps
Click ✅ Mark Solution

On mobile, press and hold the message, then look for Apps → Mark Solution.

If you want, I can also help with the original gateway warning/config question.

#[gateway] starting...