openclaw - 💡(How to fix) Fix [Bug]: v2026.4.27 fails during config load with EACCES on /var/lib/openclaw/plugin-runtime-deps [4 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#74971Fetched 2026-05-01 05:39:26
View on GitHub
Comments
4
Participants
3
Timeline
9
Reactions
3
Author
Timeline (top)
commented ×4closed ×1cross-referenced ×1labeled ×1

On v2026.4.27, the gateway fails during config load with EACCES when OpenClaw tries to create /var/lib/openclaw/plugin-runtime-deps/..., causing a restart loop. In this deployment the gateway is intentionally sealed and runtime dependency installation is not allowed; v2026.4.23 works in the same setup.

Error Message

Relevant log excerpt:

Failed to read config at /home/node/.openclaw/openclaw.json Error: EACCES: permission denied, mkdir '/var/lib/openclaw/plugin-runtime-deps/openclaw-2026.4.27-f53b52ad6d21'

[openclaw] CLI failed: Error: EACCES: permission denied, mkdir '/var/lib/openclaw/plugin-runtime-deps/openclaw-2026.4.27-f53b52ad6d21'

Stack trace includes:

  • ensureBundledPluginRuntimeDeps
  • prepareBundledPluginRuntimeRoot
  • loadBundledPluginPublicArtifactModuleSync
  • tryLoadBundledProviderPolicySurface
  • resolveBundledProviderPolicySurface
  • normalizeProviderConfigForConfigDefaults
  • applyModelDefaults
  • materializeRuntimeConfig
  • validateConfigObject

The container restart policy is: unless-stopped

Observed behavior:

  • container starts
  • exits during config load
  • Docker restarts it
  • the same EACCES error repeats

Root Cause

Actual result: The gateway fails during config load because it tries to create a directory under /var/lib/openclaw/plugin-runtime-deps and gets EACCES, after which the container restarts.

Fix Action

Fix / Workaround

Docker Desktop on Windows / WSL2. Repository updated to v2026.4.27, then gateway container rebuilt and recreated. Container: openclaw-openclaw-gateway-1 Image: openclaw:gateway-secure-patched This deployment intentionally uses a sealed gateway container: - no runtime pip/uv/poetry installs - runtime dependency expansion is restricted - only /home/node/.openclaw is writable for config/data

Code Example

Relevant log excerpt:

Failed to read config at /home/node/.openclaw/openclaw.json Error: EACCES: permission denied, mkdir '/var/lib/openclaw/plugin-runtime-deps/openclaw-2026.4.27-f53b52ad6d21'

[openclaw] CLI failed: Error: EACCES: permission denied, mkdir '/var/lib/openclaw/plugin-runtime-deps/openclaw-2026.4.27-f53b52ad6d21'

Stack trace includes:
- ensureBundledPluginRuntimeDeps
- prepareBundledPluginRuntimeRoot
- loadBundledPluginPublicArtifactModuleSync
- tryLoadBundledProviderPolicySurface
- resolveBundledProviderPolicySurface
- normalizeProviderConfigForConfigDefaults
- applyModelDefaults
- materializeRuntimeConfig
- validateConfigObject

The container restart policy is:
unless-stopped

Observed behavior:
- container starts
- exits during config load
- Docker restarts it
- the same EACCES error repeats
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On v2026.4.27, the gateway fails during config load with EACCES when OpenClaw tries to create /var/lib/openclaw/plugin-runtime-deps/..., causing a restart loop. In this deployment the gateway is intentionally sealed and runtime dependency installation is not allowed; v2026.4.23 works in the same setup.

Steps to reproduce

  1. Start from a working Docker Desktop / Windows / WSL2 setup on v2026.4.23.

  2. Use a sealed gateway deployment where runtime dependency installation is intentionally restricted:

    • no runtime pip/uv/poetry installs
    • no local venv creation inside the container
    • only /home/node/.openclaw is writable for config/data
    • /var/lib/openclaw/plugin-runtime-deps is not writable for the runtime user
  3. Update the repository to v2026.4.27.

  4. Rebuild and recreate the gateway container.

  5. Start the gateway container.

  6. Follow the logs with:

    docker logs -f openclaw-openclaw-gateway-1

  7. Observe that the container enters a restart loop and repeatedly logs an EACCES error while reading /home/node/.openclaw/openclaw.json.

Expected result: The gateway should load the config successfully and continue normal startup.

Actual result: The gateway fails during config load because it tries to create a directory under /var/lib/openclaw/plugin-runtime-deps and gets EACCES, after which the container restarts.

Expected behavior

The gateway should read and validate openclaw.json successfully, then continue normal startup and become healthy.

Actual behavior

On v2026.4.27, the gateway fails during config load and enters a restart loop. The error is:

EACCES: permission denied, mkdir '/var/lib/openclaw/plugin-runtime-deps/openclaw-2026.4.27-f53b52ad6d21'

In this deployment, the gateway container is intentionally sealed: runtime dependency installation is not allowed, and /var/lib/openclaw/plugin-runtime-deps is not writable for the runtime user by design.

The stack trace shows this happens while resolving bundled provider policy surfaces during config normalization / applyModelDefaults, before normal gateway startup completes.

OpenClaw version

2026.2.27

Operating system

Windows 11

Install method

Docker Desktop on Windows / WSL2. Repository updated to v2026.4.27, then gateway container rebuilt and recreated. Container: openclaw-openclaw-gateway-1 Image: openclaw:gateway-secure-patched This deployment intentionally uses a sealed gateway container: - no runtime pip/uv/poetry installs - runtime dependency expansion is restricted - only /home/node/.openclaw is writable for config/data

Model

openai/gpt-5.4-mini

Provider / routing chain

Configured routing includes OpenAI, Gemini, and Ollama-backed models. The failure occurs during provider/config normalization before the selected runtime model is actually used.

Additional provider/model setup details

The issue appears while processing model defaults / provider policy surfaces during config loading.

Relevant config area:

  • agents.defaults.model.primary / fallbacks
  • agent model.primary / fallbacks entries

The crash is triggered before normal gateway startup, not during an actual user model call.

Logs, screenshots, and evidence

Relevant log excerpt:

Failed to read config at /home/node/.openclaw/openclaw.json Error: EACCES: permission denied, mkdir '/var/lib/openclaw/plugin-runtime-deps/openclaw-2026.4.27-f53b52ad6d21'

[openclaw] CLI failed: Error: EACCES: permission denied, mkdir '/var/lib/openclaw/plugin-runtime-deps/openclaw-2026.4.27-f53b52ad6d21'

Stack trace includes:
- ensureBundledPluginRuntimeDeps
- prepareBundledPluginRuntimeRoot
- loadBundledPluginPublicArtifactModuleSync
- tryLoadBundledProviderPolicySurface
- resolveBundledProviderPolicySurface
- normalizeProviderConfigForConfigDefaults
- applyModelDefaults
- materializeRuntimeConfig
- validateConfigObject

The container restart policy is:
unless-stopped

Observed behavior:
- container starts
- exits during config load
- Docker restarts it
- the same EACCES error repeats

Impact and severity

High. The gateway never reaches normal startup on v2026.4.27 in this setup, so OpenClaw is unusable until rolling back to v2026.4.23.

Additional information

Previous working version: v2026.4.23

Earlier failing versions in the same setup:

  • v2026.4.24
  • v2026.4.25
  • v2026.4.26

Those versions failed later in startup around “starting channels and sidecars...”. v2026.4.27 fails earlier during config load with EACCES on /var/lib/openclaw/plugin-runtime-deps.

extent analysis

TL;DR

The most likely fix is to modify the gateway configuration to avoid attempting to create directories under /var/lib/openclaw/plugin-runtime-deps, which is not writable for the runtime user.

Guidance

  • Review the ensureBundledPluginRuntimeDeps function to understand why it's trying to create a directory under /var/lib/openclaw/plugin-runtime-deps.
  • Consider modifying the prepareBundledPluginRuntimeRoot function to use a writable directory for the runtime user.
  • Check the loadBundledPluginPublicArtifactModuleSync function to see if it can be modified to avoid relying on /var/lib/openclaw/plugin-runtime-deps.
  • Verify that the applyModelDefaults function is correctly handling the case where /var/lib/openclaw/plugin-runtime-deps is not writable.

Example

No code snippet is provided as the issue is more related to configuration and directory permissions.

Notes

The issue seems to be related to the introduction of a new feature or change in the v2026.4.27 version that is trying to create directories under /var/lib/openclaw/plugin-runtime-deps, which is not allowed in the sealed gateway deployment.

Recommendation

Apply a workaround by modifying the gateway configuration to use a writable directory for the runtime user, as the issue is likely due to a change in the v2026.4.27 version that is not compatible with the sealed gateway deployment.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The gateway should read and validate openclaw.json successfully, then continue normal startup and become healthy.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Bug]: v2026.4.27 fails during config load with EACCES on /var/lib/openclaw/plugin-runtime-deps [4 comments, 3 participants]