openclaw - 💡(How to fix) Fix Feature request: $include directive for string values (e.g. systemPromptOverride)

Problem

The $include directive currently works at the object level in config JSON, allowing external files to be merged into object structures. However, it does not work for string values — the included file's contents are not resolved as a plain string.

This matters because systemPromptOverride (and potentially other config fields) are string fields where the value can be long, complex, and independently maintained. There's no way to reference an external file for these fields today.

Proposed Solution

Support $include as a string value resolver. When $include appears as the sole key in an object that is assigned to a string-typed field, resolve it by reading the referenced file and using its contents as the string value.

Example config:

{
  "agents": {
    "defaults": {
      "systemPromptOverride": { "$include": "./system-prompt.md" }
    }
  }
}

Resolution: The contents of system-prompt.md (relative to the config file) become the string value of systemPromptOverride.

This is analogous to how #include works in C/C++ — textual inclusion of file contents.

Why This Matters

• systemPromptOverride is a large, complex string — maintaining it inline in JSON (with all the escaping that entails) is error-prone and hard to diff across versions.
• Separation of concerns — the system prompt is a document, not a config value. It should live in its own file where it can be edited, version-controlled, and diffed naturally.
• Markdown/prose in JSON strings is painful — newlines require \n, quotes require escaping, and the result is unreadable in the config file. An external .md file is the natural format.
• Consistency — $include already works for objects. Extending it to strings completes the pattern.

Additional Context

This is a companion request to #82835 (preamble-only override). Even if a lightweight preamble override is added, there are still cases where full systemPromptOverride is needed — and when it is, maintaining it as an external file via $include would be significantly more ergonomic than inline JSON strings.