openclaw - 💡(How to fix) Fix Gateway writes new memory.qmd.update keys to user config + auto-restarts without user authorization

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…

Code Example

"memory": {
  "qmd": {
    "update": {
       "onBoot": true,
+      "embedInterval": "24h",
+      "embedTimeoutMs": 600000

---

[reload] config change requires gateway restart (memory.qmd.update.embedInterval)
RAW_BUFFERClick to expand / collapse

Reproducible on 2026.4.23.

What happened

At 2026-05-23T20:43:57Z, the gateway silently appended two keys to my hand-managed ~/.openclaw/openclaw.json:

"memory": {
  "qmd": {
    "update": {
       "onBoot": true,
+      "embedInterval": "24h",
+      "embedTimeoutMs": 600000

Seven seconds later (2026-05-23T20:44:04Z), the gateway auto-restarted itself, with this journal line:

[reload] config change requires gateway restart (memory.qmd.update.embedInterval)

I did not edit the config. No user-initiated action triggered this. No prompt, no notification, no opt-in.

Why this is a bug

  1. User config is sacred. OC writing to it without the user's hand on the keyboard is the same trust violation as #85080 (silent reverts on update) and #85809 (stripping plugins.entries.<id>.hooks on startup) — but in the OPPOSITE direction: injection instead of strip.
  2. Auto-restarting the gateway is operationally hostile. Gateway restart = dropped sessions, dropped Signal/Discord connections, in-flight tool calls lost. This is a blast-radius decision that belongs to the user, not to OC.
  3. The values written happen to be sensible (24h interval + 10min timeout for the qmd embed loop that was hot-looping on an empty XDG dir) — but "we made a good guess" doesn't justify writing without consent. Surface the recommendation; let the user apply it.
  4. Pattern: combined with #85080 + #85809, OC's config normalizer is now demonstrably non-idempotent in three modes (silent revert, silent strip, silent inject). Users cannot trust their own openclaw.json.

Asks

  1. Never write user ~/.openclaw/openclaw.json from background gateway logic. If a new key needs to be set, surface it as a doctor recommendation that the user explicitly applies.
  2. Never auto-restart the gateway from a config-change reload. If a restart is needed, queue an openclaw needs-restart notification surface and let the user pick the window.
  3. If both 1 and 2 must remain for some reason, gate them behind an explicit gateway.allowAutonomousConfigWrites=true opt-in (default false).
  4. Audit-log: when OC does write to user config, write the change to a user-visible audit log (not just systemd journal) with timestamp + source.

Cross-reference

Same trust class as #85080 and #85809. Likely same code path. Version 2026.4.23. Stack: Linux systemd openclaw-gateway.service (user-level).

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…

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 Gateway writes new memory.qmd.update keys to user config + auto-restarts without user authorization