openclaw - 💡(How to fix) Fix sudo openclaw update can create mixed ownership, then doctor overwrites config after EACCES/read failure [1 comments, 2 participants]

Summary

On macOS / LaunchAgent, running sudo openclaw update against a user-local install upgraded OpenClaw successfully, but it also left OpenClaw state/config/plugin files with mixed root/user ownership. A later normal-user openclaw doctor hit EACCES reading ~/.openclaw/openclaw.json, continued with best-effort config, and eventually overwrote the real config with a 330-byte skeletal file.

The command detected a dangerous write anomaly:

size-drop-vs-last-good:14992->330, gateway-mode-missing-vs-last-good

but still wrote the bad config. The gateway then refused to start because gateway.mode was missing, which matches current docs saying an existing config missing gateway.mode=local should be treated as broken/clobbered.

Environment

• OS: macOS, LaunchAgent gateway
• OpenClaw before update: 2026.5.3-1
• OpenClaw after update: 2026.5.5 (b1abf9d)
• Gateway port: 18789
• User UID/GID: 501:20
• Install root: ~/.local/lib/node_modules/openclaw
• State/config dir: ~/.openclaw

Reproduction / observed sequence

1. Run:

   sudo openclaw update

2. Update reports success:

   Update Result: OK
   Before: 2026.5.3-1
   After: 2026.5.5

3. During the sudo-run update, plugin warnings appear because root sees user-owned plugin candidates as suspicious:

   blocked plugin candidate: suspicious ownership
   ... uid=501, expected uid=0 or root

4. Plugin update/config write then proceeds under sudo/root anyway.

5. Gateway refresh fails with the documented "wrong user / sudo" class of error:

   updated install refresh failed (.../openclaw/dist/index.js):
   This usually means you are running from SSH/headless context or as the wrong user (including sudo).
   Fix: sign in to the macOS desktop as the target user and rerun
   `openclaw gateway install --force`.

6. Running as the normal user:

   openclaw doctor

   repeatedly reports:

   EACCES: permission denied, open '~/.openclaw/openclaw.json'
   Config file is not readable by the current process.

7. Doctor continues with best-effort config and later writes:

   Config overwrite: ~/.openclaw/openclaw.json
   Config write anomaly: ... missing-meta-before-write
   Config observe anomaly: ... size-drop-vs-last-good:14992->330, gateway-mode-missing-vs-last-good
   Updated ~/.openclaw/openclaw.json

Local evidence after the failure

Current config is only 330 bytes and contains only:

{
  "channels": { "telegram": { "enabled": true } },
  "wizard": { "...": "..." },
  "meta": { "...": "..." }
}

Recovered backup shape is intact:

• ~/.openclaw/openclaw.json.last-good: 14986 bytes
• includes gateway.mode = "local"
• includes gateway.port = 18789
• includes gateway.auth.mode = "token"
• includes agents.list with 5 entries
• includes plugins.entries

Root-owned / mixed ownership files produced or left around include:

~/.openclaw/plugins/installs.json                         root:staff
~/.openclaw/plugin-skills                                 root:staff
~/.openclaw/npm/node_modules/@openclaw/brave-plugin       root:staff
~/.openclaw/npm/node_modules/@openclaw/codex              root:staff
~/.local/lib/node_modules/openclaw                        root:staff
~/.local/bin/openclaw                                     root:staff symlink

openclaw gateway status --json --no-probe reports the service is installed/running but last start failed:

Gateway start blocked: existing config is missing gateway.mode.
Treat this as suspicious or clobbered config.

Expected behavior

OpenClaw should fail closed when the config cannot be read due to EACCES, especially if the command is about to write ~/.openclaw/openclaw.json.

It should not serialize a best-effort/empty/default config over a previously valid config when:

• config read failed,
• openclaw.json.last-good exists,
• the proposed write is a massive size drop,
• gateway.mode is missing compared to last-good,
• or the process effective UID differs from the owner of the user state directory.

Suggested fix

1. In config-writing paths, treat EACCES / unreadable config as a hard blocker for full-file overwrites.
2. If loader is in best-effort config mode, allow read-only diagnostics but block writes unless an explicit recovery command is used.
3. Upgrade the existing "Config write anomaly" detector from warning-only to fail-closed for severe cases like:
   • size-drop-vs-last-good
   • gateway-mode-missing-vs-last-good
   • missing meta before write after failed read
4. Write the rejected candidate to openclaw.json.rejected.<timestamp> instead of replacing the live config.
5. Add a guard to openclaw update when run with sudo against a user-owned ~/.openclaw: either refuse state/config/plugin mutations or re-exec the state-mutating phase as the target user.
6. Add regression tests for:
   • unreadable openclaw.json + doctor must not overwrite config
   • last-good exists + proposed config drops gateway.mode must be rejected
   • sudo/root update against user-owned state must not leave root-owned state files
   • plugin update under wrong UID must not create mixed ownership in ~/.openclaw/npm, plugins, or plugin-skills

Workaround used locally

Restore ~/.openclaw/openclaw.json.last-good, fix ownership back to UID 501, then run openclaw gateway install --force as the logged-in macOS user, not via sudo.

Documentation cross-check

• Gateway CLI: https://docs.openclaw.ai/cli/gateway
• Gateway Runbook: https://docs.openclaw.ai/gateway/index
• Doctor: https://docs.openclaw.ai/gateway/doctor
• Plugin Internals: https://docs.openclaw.ai/plugins/architecture