CONFIGURE drops openclaw-CLI flags into the value, corrupting numeric/typed config

[mostlydev]

Summary

CONFIGURE openclaw config set <path> <value> --json in a Clawfile silently corrupts the resulting config: the --json token gets concatenated into the value, JSON parsing then fails, and the value is stored as the string \"<value> --json\". Downstream validators reject it (e.g. agents.defaults.contextTokens: expected number, received string).

The same bug bites the flag-first form (set --json <path> <value>): the parser stores --json as a literal top-level config key.

Reproduction

In any OpenClaw agent's Clawfile:

CONFIGURE openclaw config set agents.defaults.contextTokens 20000 --json

After claw up -d, the resulting .claw-runtime/<agent>/config/openclaw.json contains:

{ \"agents\": { \"defaults\": { \"contextTokens\": \"20000 --json\" } } }

…and the gateway crash-loops with:

Config invalid
File: ~/.openclaw/config/openclaw.json
Problem:
  - agents.defaults.contextTokens: Invalid input: expected number, received string

Root cause

internal/driver/shared/config.go:50 — ParseConfigSetCommand tokenizes the line with strings.Fields and treats everything after parts[3] (the path) as the value:

path = strings.TrimSpace(parts[3])
valueText := strings.TrimSpace(strings.Join(parts[4:], \" \"))

CLI-style flags are not recognized, so they leak into the value text and break the json.Unmarshal fallback.

Why this is confusing

• The shell-level openclaw config set <path> <value> --json works, so the syntax looks transferable.
• The parser already attempts json.Unmarshal first, so --json is semantically a no-op for CONFIGURE — it just shouldn't break parsing.
• Without --json, CONFIGURE openclaw config set agents.defaults.contextTokens 20000 does work (the 20000 JSON-parses to a number). But operators copy the documented CLI form and trip over it.

Proposed fix

In ParseConfigSetCommand, strip recognized openclaw-CLI flags (--json, --strict-json) from the token list before extracting path/value. The flags are accepted but have no effect (the parser already attempts JSON parsing). This preserves the documented CLI signature without changing semantics.

Add unit tests for:

• <prefix> config set <path> <value> --json (flag after value)
• <prefix> config set --json <path> <value> (flag before path)
• <prefix> config set --strict-json <path> <value> (alias)
• Existing no-flag behavior (regression coverage)

Real-world impact

Discovered on the Tiverton trading desk: 4 agent Clawfiles carried this line, copied from the openclaw CLI docs. Sentinel crash-looped on its first rebuild. Three other agents (_shared, dundas, allen) silently never set their intended contextTokens — the value was instead stored as a string \"<n> --json\" which OpenClaw then dropped during validation, leaving the field at default. The desk discovered the problem only because a separate bind-mount fix forced a rebuild that exposed the validation crash on the one agent (sentinel) whose config was non-null.

Proposed labels

bug