openclaw - 💡(How to fix) Fix [Bug]: `openclaw config set meta.lastTouchedVersion` and `meta.lastTouchedAt` report `Updated …` success while `stampConfigVersion` silently overrides the value at write time — reproduces on `v2026.5.7` and `v2026.5.10-beta.1` [4 pull requests]

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…

openclaw config set meta.lastTouchedVersion <any-value> and openclaw config set meta.lastTouchedAt <any-value> print Updated meta.lastTouchedVersion. Restart the gateway to apply. (or the equivalent for lastTouchedAt) and write the canonical openclaw.json with a new sha256, but the on-disk value is not the value the user passed — it is always the current VERSION constant for lastTouchedVersion and the current ISO timestamp for lastTouchedAt. The override happens in stampConfigVersion() at src/config/io.ts:897-908, called unconditionally at src/config/io.ts:2114 for every config-write pipeline. config set reports false success — same symptom class as the closed #79856 ("config set returns success while discarding values that match schema defaults — silent data loss"), but a distinct code path that #79856's fix (#80106) does not touch.

Error Message

  1. Warn loudly that the user's value will be overwritten by the auto-stamp: Warning: meta.lastTouchedVersion is auto-managed by stampConfigVersion; your value will not persist.

Root Cause

Both fields are overwritten on every call; user input never wins because the spread ...cfg.meta is sequenced before the two explicit overrides.

Fix Action

Fixed

Code Example

pnpm openclaw config set meta.lastTouchedVersion 'BOGUS-NOT-A-VERSION'
   pnpm openclaw config set meta.lastTouchedAt       '1999-01-01T00:00:00.000Z'

---

BEFORE disk: "lastTouchedVersion": "2026.5.10-beta.1"

$ pnpm openclaw config set meta.lastTouchedVersion 'BOGUS-NOT-A-VERSION'
Config overwrite: /home/orin/.openclaw/openclaw.json (sha256 1492da9bb89… -> 43873cf614…, backup=/home/orin/.openclaw/openclaw.json.bak)
Updated meta.lastTouchedVersion. Restart the gateway to apply.

AFTER disk:  "lastTouchedVersion": "2026.5.10-beta.1"      ← user's value silently dropped
AFTER via 'config get meta.lastTouchedVersion':
2026.5.10-beta.1

---

BEFORE disk: "lastTouchedAt": "2026-05-12T00:59:11.762Z"

$ pnpm openclaw config set meta.lastTouchedAt '1999-01-01T00:00:00.000Z'
Config overwrite: /home/orin/.openclaw/openclaw.json (sha256 43873cf614… -> fc132f02b4…, backup=/home/orin/.openclaw/openclaw.json.bak)
Updated meta.lastTouchedAt. Restart the gateway to apply.

AFTER disk:  "lastTouchedAt": "2026-05-12T00:59:42.441Z"   ← current ISO timestamp, not 1999

---

function stampConfigVersion(cfg: OpenClawConfig): OpenClawConfig {
    const now = new Date().toISOString();
    return {
      ...cfg,
      meta: {
        ...cfg.meta,
        lastTouchedVersion: VERSION,
        lastTouchedAt: now,
      },
    };
  }

---

const stampedOutputConfig = stampConfigVersion(outputConfig);
  const json = JSON.stringify(stampedOutputConfig, null, 2).trimEnd().concat("\n");

---

"meta.lastTouchedVersion": "Auto-set when OpenClaw writes the config.",
"meta.lastTouchedAt":       "ISO timestamp of the last config write (auto-set).",

---
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

openclaw config set meta.lastTouchedVersion <any-value> and openclaw config set meta.lastTouchedAt <any-value> print Updated meta.lastTouchedVersion. Restart the gateway to apply. (or the equivalent for lastTouchedAt) and write the canonical openclaw.json with a new sha256, but the on-disk value is not the value the user passed — it is always the current VERSION constant for lastTouchedVersion and the current ISO timestamp for lastTouchedAt. The override happens in stampConfigVersion() at src/config/io.ts:897-908, called unconditionally at src/config/io.ts:2114 for every config-write pipeline. config set reports false success — same symptom class as the closed #79856 ("config set returns success while discarding values that match schema defaults — silent data loss"), but a distinct code path that #79856's fix (#80106) does not touch.

Steps to reproduce

  1. On v2026.5.7 (today's npm stable; commit eeef486449) or v2026.5.10-beta.1 (today's beta; commit 9c7e67b0f8). Bug reproduces on both — verified by inspecting stampConfigVersion in each tag's source (src/config/io.ts:885 on v2026.5.7, src/config/io.ts:897 on current main).

  2. Run two commands targeting the auto-managed meta.* paths:

    pnpm openclaw config set meta.lastTouchedVersion 'BOGUS-NOT-A-VERSION'
    pnpm openclaw config set meta.lastTouchedAt       '1999-01-01T00:00:00.000Z'
  3. After each command, the CLI prints Updated meta.lastTouchedVersion. Restart the gateway to apply. (or the lastTouchedAt equivalent), with a new sha256 in the Config overwrite: log line — making it look like the write persisted.

  4. Inspect the disk: meta.lastTouchedVersion is still the package's VERSION (e.g. 2026.5.10-beta.1); meta.lastTouchedAt is the current ISO timestamp, not 1999-01-01T00:00:00.000Z.

Expected behavior

One of:

  1. Reject the write at the config set boundary for paths known to be auto-managed (meta.lastTouchedVersion, meta.lastTouchedAt, and any future siblings stamped by stampConfigVersion). Schema help already documents meta.lastTouchedAt as "ISO timestamp of the last config write (auto-set)." (src/config/schema.help.ts:7) — the CLI should surface that same fact and refuse the write.
  2. Warn loudly that the user's value will be overwritten by the auto-stamp: Warning: meta.lastTouchedVersion is auto-managed by stampConfigVersion; your value will not persist.
  3. Whatever the chosen UX, the CLI must not print Updated meta.lastTouchedVersion. when the on-disk value is unchanged.

Actual behavior

Verbatim live capture on this box (current main 033ecc944d, package.json 2026.5.10-beta.1, also reproduces on v2026.5.7 source as shown below):

BEFORE disk: "lastTouchedVersion": "2026.5.10-beta.1"

$ pnpm openclaw config set meta.lastTouchedVersion 'BOGUS-NOT-A-VERSION'
Config overwrite: /home/orin/.openclaw/openclaw.json (sha256 1492da9bb89… -> 43873cf614…, backup=/home/orin/.openclaw/openclaw.json.bak)
Updated meta.lastTouchedVersion. Restart the gateway to apply.

AFTER disk:  "lastTouchedVersion": "2026.5.10-beta.1"      ← user's value silently dropped
AFTER via 'config get meta.lastTouchedVersion':
2026.5.10-beta.1
BEFORE disk: "lastTouchedAt": "2026-05-12T00:59:11.762Z"

$ pnpm openclaw config set meta.lastTouchedAt '1999-01-01T00:00:00.000Z'
Config overwrite: /home/orin/.openclaw/openclaw.json (sha256 43873cf614… -> fc132f02b4…, backup=/home/orin/.openclaw/openclaw.json.bak)
Updated meta.lastTouchedAt. Restart the gateway to apply.

AFTER disk:  "lastTouchedAt": "2026-05-12T00:59:42.441Z"   ← current ISO timestamp, not 1999

Tracing in source on v2026.5.10-beta.1:

  • src/config/io.ts:897-908 defines stampConfigVersion:

    function stampConfigVersion(cfg: OpenClawConfig): OpenClawConfig {
      const now = new Date().toISOString();
      return {
        ...cfg,
        meta: {
          ...cfg.meta,
          lastTouchedVersion: VERSION,
          lastTouchedAt: now,
        },
      };
    }

    Both fields are overwritten on every call; user input never wins because the spread ...cfg.meta is sequenced before the two explicit overrides.

  • src/config/io.ts:2114 calls it unconditionally on the serialization path:

    const stampedOutputConfig = stampConfigVersion(outputConfig);
    const json = JSON.stringify(stampedOutputConfig, null, 2).trimEnd().concat("\n");

    This sits after any user-mutation logic (including the explicitSetPaths mechanism that #80106 added to fix #79856), so even an explicitly-set user value targeting meta.lastTouchedVersion / meta.lastTouchedAt is undone immediately before the JSON is written.

  • The config set CLI handler emits the success line in src/cli/config-cli.ts regardless of whether the post-write value matches the requested value. It only checks that a write happened (sha256 changed because lastTouchedAt was re-stamped) — not that the user's intended write was persisted.

Schema help already documents both fields as auto-managed (src/config/schema.help.ts:6-7):

"meta.lastTouchedVersion": "Auto-set when OpenClaw writes the config.",
"meta.lastTouchedAt":       "ISO timestamp of the last config write (auto-set).",

So the field semantics are intentional. The defect is that config set doesn't honor those documented semantics at the CLI boundary.

OpenClaw version

v2026.5.10-beta.1

Operating system

Ubuntu 24.04

Install method

No response

Model

Not applicable

Provider / routing chain

Not applicable.

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

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

One of:

  1. Reject the write at the config set boundary for paths known to be auto-managed (meta.lastTouchedVersion, meta.lastTouchedAt, and any future siblings stamped by stampConfigVersion). Schema help already documents meta.lastTouchedAt as "ISO timestamp of the last config write (auto-set)." (src/config/schema.help.ts:7) — the CLI should surface that same fact and refuse the write.
  2. Warn loudly that the user's value will be overwritten by the auto-stamp: Warning: meta.lastTouchedVersion is auto-managed by stampConfigVersion; your value will not persist.
  3. Whatever the chosen UX, the CLI must not print Updated meta.lastTouchedVersion. when the on-disk value is unchanged.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING