Bug type

Behavior bug / deployment wrapper config corruption

Summary

When OpenClaw is launched under the u4s-openclaw wrapper, every restart rewrites /data/.openclaw/openclaw.json back to a minimal baseline and discards user config changes for WhatsApp access control and other protected settings.

This breaks WhatsApp inbound/outbound authorization after restart even when the config was correct on disk before the restart.

Environment

• OpenClaw version: 2026.5.7
• Install path in container: /data/.npm-global/bin/openclaw
• Runtime wrapper: /app/u4s-openclaw
• Process tree:
  • tini -- /app/u4s-openclaw
  • /app/u4s-openclaw
  • openclaw
• Container cwd observed for config-mutating startup processes: /app
• OS inside runtime: Linux container

Expected behavior

If the user sets:

• channels.whatsapp.allowFrom
• channels.whatsapp.groupAllowFrom
• commands.ownerAllowFrom
• tools.elevated.allowFrom.webchat
• agents.list[0].tools.elevated.allowFrom.webchat
• channels.discord/slack/telegram.enabled

then those values should survive a gateway restart.

Actual behavior

After restart, config is rewritten and reverts to a baseline such as:

• channels.whatsapp.allowFrom -> only the linked self number remains
• channels.whatsapp.groupAllowFrom -> only the linked self number remains
• commands.ownerAllowFrom disappears
• tools.elevated.allowFrom.webchat reverts to [*]
• agents.list[0].tools.elevated.allowFrom.webchat reverts to [*]
• channels.discord.enabled/slack.enabled/telegram.enabled revert to true

As a consequence, WhatsApp DM allowlist behavior breaks after restart:

• inbound from the owner number stops working
• outbound message tool sends to the owner fail with:
  • Target "+<redacted>" is not listed in the configured WhatsApp allowFrom policy.

Key evidence

1) Config audit shows startup processes rewriting config

/data/.openclaw/logs/config-audit.jsonl records startup writes like:

• openclaw plugins enable whatsapp
• openclaw plugins enable telegram
• openclaw plugins enable discord
• openclaw plugins enable slack
• openclaw gateway run --port 18789 --bind loopback

All of them write /data/.openclaw/openclaw.json with cwd=/app.

Example sequence observed after restart:

• 09:00:20 plugins enable whatsapp
• 09:00:25 plugins enable telegram
• 09:00:46 plugins enable discord
• 09:00:51 plugins enable slack
• 09:00:54 gateway run

Immediately after this sequence, the config has already been reverted.

2) The reverted state is persisted as “good”

Even these files become contaminated with the reverted baseline:

• /data/.openclaw/openclaw.json.last-good
• /data/.openclaw/openclaw.json.bak

Observed reverted baseline includes:

{
  "channels": {
    "whatsapp": {
      "allowFrom": ["+SELF_REDACTED"],
      "dmPolicy": "allowlist",
      "enabled": true,
      "groupAllowFrom": ["+SELF_REDACTED"],
      "selfChatMode": true
    },
    "discord": {"enabled": true},
    "slack": {"enabled": true},
    "telegram": {"enabled": true}
  },
  "tools": {
    "elevated": {
      "allowFrom": {"webchat": ["*"]},
      "enabled": true
    }
  }
}

3) Disk config and runtime diverge

We were able to write the correct config on disk (including owner allowlists and WhatsApp allowFrom entries), but after restart:

• openclaw channels status --deep --channel whatsapp only shows the self number in allowlist
• outbound send fails because the runtime believes the target is not in allowFrom

Reproduction outline

1. Run OpenClaw under the u4s-openclaw wrapper.
2. Configure WhatsApp with self-chat mode and add an additional owner number to channels.whatsapp.allowFrom and groupAllowFrom.
3. Restrict tools.elevated.allowFrom.webchat to a narrow value.
4. Disable Discord/Slack/Telegram.
5. Restart gateway / restart the wrapped service.
6. Observe config audit writes from /app startup processes.
7. Observe openclaw.json reverted and runtime status reflecting only the self number.

Why this matters

This is not just cosmetic config drift. It breaks:

• WhatsApp owner DM access
• outbound replies to the owner via WhatsApp
• hardened elevated/webchat restrictions
• channel enable/disable choices

Suspected root cause

Either:

1. u4s-openclaw applies a baked/derived startup baseline over user config on every restart, or
2. plugins enable ... / startup reconciliation is rebuilding config from incomplete defaults and then gateway run promotes that rewritten state.

Related issues

Potentially adjacent, but not the same root cause:

• Hot-enabling channels.whatsapp.enabled silently reverts to false when WhatsApp plugin is not loaded #78404 Hot-enabling channels.whatsapp.enabled silently reverts to false when WhatsApp plugin is not loaded
• WhatsApp selfChatMode / access-control issues such as bug(whatsapp): selfChatMode config field not consumed in access-control #23788, [Bug]: WhatsApp selfChatMode fires on all outbound DMs, not just self-chat — agent responded to third-party contacts #32632

Request

Please investigate the startup path used by u4s-openclaw and confirm why restart-time config reconciliation is overwriting user-edited config.

At minimum, restart should not discard explicit user values for:

• WhatsApp allowlists
• owner allowlists
• elevated webchat restrictions
• enabled/disabled channels