Summary

After the #1973 fix, openclaw config set <key> <value> inside the sandbox correctly refuses to silently stub-write. The replacement check is isRecognizedConfigPath(<key>). That check appears to be implemented as "exists in the currently-loaded config", not "is in the schema." Consequence: any valid-per-schema key that the user has not yet populated is rejected with the same validator message as a typo. The supported-keys set at runtime is dynamic and smaller than the supported-keys set at design time, which breaks every first-set scenario.

Concrete hit: Horace (our OpenClaw agent) needs timeoutSeconds: 600 on the compatible-endpoint inference provider to work around openclaw/openclaw#64432 ("LLM idle timeout kills Ollama streams during reasoning phases", still open). The documented override path is openclaw config set provider.compatible-endpoint.timeoutSeconds 600. That command is rejected as "not a recognized config path" on a freshly-onboarded sandbox where the key has never been written. The only way to get the value in is to drop out of config set and hand-edit openclaw.json via kubectl exec, bypassing the validator the same way nemoclaw does internally.

Adjacent context

This builds on #1973 (closed 2026-04-20): openclaw config set no longer silently stub-writes, it now validates, which is the correct direction. The validator's rejection rule is just too strict; it rejects any key path that isn't already present in the target config file.

Reproduction

1. curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash (fresh install, 0.0.23).
2. nemoclaw onboard through to a running sandbox.
3. nemoclaw <sandbox> connect.
4. Inside the sandbox: openclaw config set provider.compatible-endpoint.timeoutSeconds 600
5. Observe error: validator rejects the key as unrecognized.
6. Confirm the key is schema-valid: the NemoClaw blueprint and the OpenClaw provider loader both accept this path when present in openclaw.json.

Live repro, 2026-04-23

Command + output (sandbox my-assistant, v0.0.23):

dietpi@my-assistant:/sandbox$ openclaw config set provider.compatible-endpoint.timeoutSeconds 600
Error: config path 'provider.compatible-endpoint.timeoutSeconds' is not recognized
dietpi@my-assistant:/sandbox$ cat /sandbox/.openclaw/openclaw.json | jq 'keys'
[... <keys present on this sandbox>, no "provider" entry yet ...]
dietpi@my-assistant:/sandbox$ # workaround used today:
dietpi@my-assistant:/sandbox$ kubectl --kubeconfig /etc/rancher/k3s/k3s.yaml \
    exec -it my-assistant -- \
    sh -c 'jq ".provider[\"compatible-endpoint\"].timeoutSeconds = 600" \
      /sandbox/.openclaw/openclaw.json > /tmp/o.json && mv /tmp/o.json /sandbox/.openclaw/openclaw.json'
# success
dietpi@my-assistant:/sandbox$ openclaw config get provider.compatible-endpoint.timeoutSeconds
600

The config set command rejects; the direct jq write through the same file succeeds; config get then reports the key as present. The validator's "recognized" definition and the schema's "valid" definition disagree.

Hypothesis on root cause

isRecognizedConfigPath is implemented against the in-memory merged config object (or against the current openclaw.json file), not against a schema. A key that exists in the schema but hasn't been written yet is indistinguishable from a typo at that layer. The #1973 fix correctly stopped the silent stub-write; it replaced one failure mode with another.

What would fix this

• Validate against the schema, not the currently-loaded config. The supported-keys set at runtime should be the union of "every key in the current config" and "every key the schema accepts."
• If a typo'd path should still be caught, catch it with a fuzzy-match warning ("Did you mean provider.compatible-endpoint.timeoutSeconds?") rather than a hard rejection.
• Consider surfacing the schema in openclaw config schema (read-only) so users can discover which paths are set-able without running a trial-and-error loop.

Environment

• Host: Debian 13 (Trixie) kernel 6.12.74+deb13+1-amd64 on Intel NUC i7-10710U
• NemoClaw: 0.0.23
• OpenShell: 0.0.32
• OpenClaw: 2026.4.2 (sandbox image digest b3d832b596...)
• Sandbox: my-assistant
• Inference provider: compatible-endpoint pointing at an external Ollama (ROCm on Radeon 890M iGPU, Qwen 3.6-35B)

Impact

Any user hitting openclaw/openclaw#64432 (Ollama reasoning stream killed by 60s idle timeout on thinking models like Qwen 3.6) who tries to follow the documented-in-comments workaround (config set provider.compatible-endpoint.timeoutSeconds <larger>) cannot apply it. They have two options:

1. Wait for #64432 to be fixed upstream, or
2. Edit openclaw.json directly via kubectl exec, which requires knowing that the sandbox runs k3s in Docker and knowing the config file's absolute path inside the container.

Both workarounds work, but neither matches the smooth first-time path implied by the documented config set override.

Workaround

See the jq-based direct edit in the repro section. It works, is unsupported, and bypasses the validator entirely.

Supporting artifacts available on request

• Full openclaw.json pre and post direct-edit
• openclaw config set --debug transcript (if a debug flag exists; not tested yet)
• Link to the #64432 comment thread where the workaround is suggested

Why this matters

A validator's job is to catch mistakes, not block legitimate first-time writes. Re-writing the check against the schema is a small, local change; the cost of leaving it as-is is that every user who hits a thinking-model timeout and reaches for the documented override discovers they cannot use it.