Summary

The OpenClaw docs describe tools.exec.approvalRunningNoticeMs as a supported config key for approval-gated exec follow-up notices, but the local 2026.3.24 (cff6dc9) build rejects that field as an unrecognized key under tools.exec.

This looks like a docs/schema mismatch rather than an operator mistake.

Version

• OpenClaw 2026.3.24 (cff6dc9)
• host: Linux

Docs claim

The exec tool docs currently state:

tools.exec.approvalRunningNoticeMs (default: 10000): emit a single “running” notice when an approval-gated exec runs longer than this (0 disables).

Relevant doc path:

• docs/tools/exec.md

Reproduction

1. Add this field under tools.exec:

{
  "tools": {
    "exec": {
      "host": "gateway",
      "security": "allowlist",
      "ask": "on-miss",
      "approvalRunningNoticeMs": 3000
    }
  }
}

1. Run any config-consuming CLI command, for example:

openclaw config get tools.exec

The command fails during config load before it can return the tools.exec object.

Actual result

The runtime rejects the config with:

Invalid config at /home/dcleres/.openclaw/openclaw.json:
- tools.exec: Unrecognized key: "approvalRunningNoticeMs"
Config invalid

This is a hard config failure, not a warning.

Expected result

One of these should be true:

1. the config schema accepts tools.exec.approvalRunningNoticeMs, or
2. the docs stop documenting it at that path for this build

Why this matters

This is easy to trip over because the documented knob is directly relevant when testing approval-gated exec follow-up behavior. Operators trying to tune the running-notice delay will hit a hard config failure even though they are following the docs.

Suspected root cause

The docs and runtime schema appear to have drifted. The key may have moved, been removed, or only exist in another schema surface, but the current tools.exec config validator on 2026.3.24 does not accept it.

Suggested fix

Either:

• restore the field in the runtime schema at tools.exec.approvalRunningNoticeMs, or
• update the docs to point at the correct supported path or remove the field for builds where it is not available

Current operator workaround

Do not set tools.exec.approvalRunningNoticeMs on 2026.3.24. The approval flow can still be tested and used successfully, but this specific knob must be treated as unsupported on this build until the docs and schema match again.

Local verification already performed

• live approval-gated exec flow works on this install
• Telegram approval routing works after enablement
• approvalRunningNoticeMs specifically fails at config-parse time when placed under tools.exec

Extra note

This issue is independent of the earlier approval follow-up heartbeat fix. The approval path itself can work correctly while this specific docs-described knob still fails schema validation.