Summary

config.write in the gateway has two related bugs that together cause plaintext secrets to leak into ~/.openclaw/openclaw.json on every config touch:

1. Atomic rename replaces symlinked config with a regular file. If ~/.openclaw/openclaw.json is a symlink (e.g. to a git-tracked workspace file), every config write clobbers the symlink with a freshly renamed regular file.
2. Resolved SecretRef values are serialized back to disk. The writer emits resolved (materialized) secret values instead of the original SecretRef marker objects, contradicting the documented behavior:

   Marker persistence is source-authoritative: OpenClaw writes markers from the active source config snapshot (pre-resolution), not from resolved runtime secret values. — docs/reference/secretref-credential-surface.md (lines 120–121)

Combined, any version-bump/self-update/config touch results in plaintext bot tokens, API keys, etc. being persisted into a newly-created regular file that replaces the user's symlink.

Environment

• OpenClaw: upgraded from 2026.4.15 → 2026.4.19-beta.2 during the reproduction
• OS: Linux 6.6.87.2-microsoft-standard-WSL2 (x64), Node v22.22.1
• Gateway mode: local, bind loopback
• Config layout (per the TOOLS.md pattern shipped in the workspace template):
  • Real file: ~/.openclaw/workspace/config/openclaw.json (git-tracked)
  • ~/.openclaw/openclaw.json → symlink to the above

Reproduction

1. Configure several fields as SecretRefs, e.g.:

   "channels": {
     "telegram": {
       "botToken": { "source": "env", "provider": "default", "id": "TELEGRAM_BOT_TOKEN" }
     }
   },
   "plugins": {
     "entries": {
       "google": {
         "config": {
           "webSearch": {
             "apiKey": { "source": "env", "provider": "default", "id": "GOOGLE_WEBSEARCH_API_KEY" }
           }
         }
       }
     }
   }

2. Put the real file at ~/.openclaw/workspace/config/openclaw.json and make ~/.openclaw/openclaw.json a symlink to it.
3. Trigger any config write — openclaw update, a meta.lastTouchedAt bump on restart, a config.patch, etc.
4. After the write:
   • ~/.openclaw/openclaw.json is no longer a symlink; it is a freshly created regular file (new inode).
   • The symlink target (workspace/config/openclaw.json) is unchanged.
   • The new regular file contains resolved plaintext values in place of the SecretRef marker objects.

Evidence from logs/config-audit.jsonl

Every write records "result":"rename" and a brand-new inode:

{"ts":"2026-04-20T14:40:18.297Z","event":"config.write","configPath":"/home/quinton/.openclaw/openclaw.json","result":"rename","previousIno":"116226","nextIno":"260737","previousNlink":1,"nextNlink":1,"gatewayModeBefore":"local","gatewayModeAfter":"local", ...}

previousNlink: 1 on the old inode is expected for a symlink's target; the key signal is nextIno differing from previousIno on every write, i.e. the writer always creates a new file and renames it over the path rather than writing through the symlink.

Observed writes today (all clobbered the symlink):

• 2026-04-20T14:29:25Z — previousIno 12575 → nextIno 21001
• 2026-04-20T14:29:33Z — previousIno 21001 → nextIno 116226
• 2026-04-20T14:40:18Z — previousIno 116226 → nextIno 260737 (coincided with lastTouchedVersion: "2026.4.15" → "2026.4.19-beta.2")

Diff of what got written

Minimum diff between the symlink target (source, with SecretRefs) and the regular file OpenClaw wrote:

-      "botToken": {
-        "source": "env",
-        "provider": "default",
-        "id": "TELEGRAM_BOT_TOKEN"
-      },
+      "botToken": "8712...REDACTED...",
...
-        "apiKey": {
-          "source": "env",
-          "provider": "default",
-          "id": "GOOGLE_WEBSEARCH_API_KEY"
-        }
+        "apiKey": "AIza...REDACTED..."

Affected fields in this repro:

• channels.telegram.botToken
• skills.entries.goplaces.apiKey
• skills.entries.notion.apiKey
• plugins.entries.google.config.webSearch.apiKey

All four are listed as supported SecretRef surfaces in docs/reference/secretref-credential-surface.md.

Expected behavior

• Symlink preservation: the config writer should resolve the real path before the temp-write + rename (e.g. fs.realpathSync(configPath) as the rename target), or write-through the symlink. Atomic replace of a user-managed symlink is surprising and breaks common deployment patterns (git-tracked config, Nix/Chezmoi/dotfiles, etc.).
• SecretRef preservation: per the documented contract, writes should serialize from the pre-resolution source config snapshot so SecretRef marker objects round-trip unchanged. Resolved plaintext values must never hit disk in the config file, regardless of what internal in-memory representation the gateway uses at runtime.

Impact

• Security. Every self-update / config touch silently exfiltrates plaintext credentials into the primary config file. Any user who assumes SecretRefs keep plaintext out of openclaw.json (as the docs state) is wrong today. If that file is shell-history-grepped, backed up, committed, or opened in a shared screenshot, the secrets leak.
• Deployment patterns break. The symlink-based workflow documented in workspace templates (TOOLS.md: "If OpenClaw ever stops following the symlink, copy the file back and drop the symlink") stops working on every write. Users either keep re-creating the symlink or give up and manage plaintext in place.
• Config drift vs. source of truth. Users who version-control workspace/config/openclaw.json find their git-tracked file silently diverging from the runtime file.

Related issues (for context, not duplicates)

• #53742 — macOS gateway install resolves SecretRef values into plaintext LaunchAgent plist (same "resolved values written to persistent artifact" class of bug, different artifact)
• #67719 — Per-agent models.json catalog generator embeds plaintext credentials for OAuth/device-auth providers
• #38622, #36754, #61585, #63969 — other places in OpenClaw where symlinks are not followed; same root symptom, different surfaces

Suggested fix direction

1. In the config writer, resolve configPath to its real path (fs.promises.realpath) before picking the temp-file directory and rename target. This fixes the symlink clobber.
2. Serialize from the source config snapshot (the one loaded before SecretRef resolution), not the runtime-resolved snapshot. An internal redactResolved(config, secretRefMap) pass before JSON.stringify would also work but is more error-prone than keeping the source snapshot around explicitly.
3. Add a writer-level assertion / test: any field listed as a supported SecretRef surface in docs/reference/secretref-credential-surface.md must not emit a string value when the in-memory runtime state was populated from a SecretRef.

Happy to test a PR.