Config-Sentinel
Use this skill whenever you are modifying OpenClaw configuration.
This is not a soft suggestion. Config changes are high-risk operations. A single bad edit can break agent routing, bindings, startup behavior, or entire multi-agent setups.
If config integrity matters, do not skip this workflow.
This skill is especially useful for:
- - manual edits to the main OpenClaw config file
- scripted config patches
- agent/binding/channel changes
- diagnosing whether a config file is malformed or incomplete
- recovering from a broken config change
Purpose
Config-Sentinel exists because successful writes are not the same as healthy config.
A config file can be:
- - syntactically broken
- structurally incomplete
- silently truncated
- internally inconsistent
- accepted by an editor but dangerous at runtime
This skill enforces a strict safety workflow:
- 1. snapshot before changes
- validate after changes
- rollback immediately if validation fails
- run health checks when config behavior looks suspicious
Approval Rule
Do not change OpenClaw config without explicit user approval.
Snapshot/rollback protects against corruption. It does not replace human approval.
The correct order is:
- 1. get approval to make the config change
- run INLINECODE0
- make the change
- run INLINECODE1
- rollback if needed
- report the result clearly
Core Workflow
Before editing config:
CODEBLOCK0
After editing config:
CODEBLOCK1
If validation fails:
CODEBLOCK2
For an on-demand health check:
CODEBLOCK3
Non-negotiable rule
Do not edit config first and hope validation will save you later.
The correct order is always:
- 1. snapshot
- edit
- validate
- rollback if needed
What It Protects Against
Config-Sentinel is designed to catch or soften failures such as:
- - malformed JSON
- incomplete or truncated config writes
- missing agent entries
- bindings that reference missing agents
- invalid channel/account structure
- missing expected config file after an edit
- accidental regressions after a patch
It also creates recovery points so rollback is straightforward.
Features
Pre-change snapshot
Before any config edit, create:
- - a timestamped backup copy
- a git snapshot when the config directory is in a git repo
- a remembered last-known-good revision for rollback
Validation
After a config change, validate:
- - JSON parseability
- presence of expected high-level keys
- minimum agent count threshold
- bindings referencing real agent ids
- optional required workspace files
- optional provider-specific checks
Rollback
Restore the last-known-good config snapshot if a change breaks structure or validation.
Health check
Run validation without making changes to assess config health.
Strict posture
This skill is intentionally strict. Config changes are one of the easiest ways to break a working OpenClaw setup.
Defaults and Overrides
The helper script uses sensible defaults, but supports environment overrides.
Default paths
- - config file: INLINECODE2
- sentinel state dir: INLINECODE3
Optional environment variables
- - INLINECODE4
- INLINECODE5
- INLINECODE6
- INLINECODE7
- INLINECODE8
- INLINECODE9
This allows the skill to adapt to different setups while keeping a strict default posture.
Best Practice Pattern
When an agent is asked to change config, the safe pattern is:
- 1. run INLINECODE10
- apply the config change
- run INLINECODE11
- if validation fails, run INLINECODE12
- tell the user clearly whether the config is healthy
Do not silently edit config without a recovery path.
Do not trust a successful write alone.
Do not continue after validation failure unless the user explicitly wants forensic inspection instead of safety.
Generic Example
Good
CODEBLOCK4
Good agent wording
- - “I created a config snapshot before editing.”
- “Validation passed after the patch.”
- “Validation failed, so I rolled back to the last-known-good config.”
Bad
- - editing config directly with no snapshot
- assuming the file is fine because the write completed
- continuing after parse errors or missing agent references
Notes
This skill does not run continuously. It is an on-demand guardrail for risky config operations.
Use it whenever config integrity matters more than speed.
If you are about to patch or rewrite config and you are tempted to skip the snapshot step, that is exactly when you should not skip it.
Summary
Config-Sentinel helps make OpenClaw config changes safer by combining:
- - snapshots
- validation
- rollback
- health checks
The goal is simple:
make config edits recoverable instead of catastrophic.
配置哨兵
当你修改OpenClaw配置时,请务必使用此技能。
这不是一个软性建议。配置变更是高风险操作。一次错误的编辑就可能导致代理路由、绑定、启动行为甚至整个多代理系统崩溃。
如果配置完整性至关重要,请不要跳过此工作流程。
此技能特别适用于:
- - 手动编辑OpenClaw主配置文件
- 脚本化配置补丁
- 代理/绑定/通道变更
- 诊断配置文件是否格式错误或不完整
- 从损坏的配置变更中恢复
目的
配置哨兵的存在是因为成功写入并不等同于配置健康。
一个配置文件可能:
- - 语法错误
- 结构不完整
- 被静默截断
- 内部不一致
- 被编辑器接受但在运行时危险
此技能强制执行严格的安全工作流程:
- 1. 变更前快照
- 变更后验证
- 验证失败立即回滚
- 配置行为可疑时运行健康检查
审批规则
未经用户明确批准,不得更改OpenClaw配置。
快照/回滚可防止损坏。它不能替代人工审批。
正确顺序是:
- 1. 获得配置变更的批准
- 运行pre-change
- 进行变更
- 运行validate
- 必要时回滚
- 清晰报告结果
核心工作流程
编辑配置前:
bash
scripts/sentinel.sh pre-change
编辑配置后:
bash
scripts/sentinel.sh validate
如果验证失败:
bash
scripts/sentinel.sh rollback
按需健康检查:
bash
scripts/sentinel.sh health
不可协商的规则
不要先编辑配置再指望验证能拯救你。
正确顺序始终是:
- 1. 快照
- 编辑
- 验证
- 必要时回滚
防范内容
配置哨兵旨在捕获或缓解以下故障:
- - 格式错误的JSON
- 不完整或被截断的配置写入
- 缺少代理条目
- 引用缺失代理的绑定
- 无效的通道/账户结构
- 编辑后缺少预期的配置文件
- 补丁后的意外回归
它还创建恢复点,使回滚变得简单直接。
功能特性
变更前快照
在任何配置编辑前,创建:
- - 带时间戳的备份副本
- 当配置目录在git仓库中时创建git快照
- 用于回滚的已知良好版本记录
验证
配置变更后,验证:
- - JSON可解析性
- 预期顶层键的存在
- 最小代理数量阈值
- 绑定引用真实代理ID
- 可选的必要工作区文件
- 可选的提供商特定检查
回滚
如果变更破坏了结构或验证失败,恢复已知良好的配置快照。
健康检查
在不进行变更的情况下运行验证,评估配置健康状态。
严格姿态
此技能故意保持严格。配置变更是破坏运行中OpenClaw设置的最简单方式之一。
默认值与覆盖
辅助脚本使用合理的默认值,但支持环境变量覆盖。
默认路径
- - 配置文件:~/.openclaw/openclaw.json
- 哨兵状态目录:~/.openclaw/.sentinel
可选环境变量
- - CONFIGSENTINELCONFIGFILE
- CONFIGSENTINELDIR
- CONFIGSENTINELMINAGENTS
- CONFIGSENTINELREQUIREDFILES
- CONFIGSENTINELVALIDATEBINDINGS
- CONFIGSENTINELVALIDATETELEGRAMTOKENS
这使得该技能能够适应不同的设置,同时保持严格的默认姿态。
最佳实践模式
当代理被要求更改配置时,安全模式是:
- 1. 运行pre-change
- 应用配置变更
- 运行validate
- 如果验证失败,运行rollback
- 清晰告知用户配置是否健康
不要在没有恢复路径的情况下静默编辑配置。
不要仅凭成功写入就信任配置。
不要在验证失败后继续操作,除非用户明确要求进行取证检查而非安全保障。
通用示例
正确做法
bash
scripts/sentinel.sh pre-change
编辑配置
scripts/sentinel.sh validate || scripts/sentinel.sh rollback
正确的代理表述
- - 我在编辑前创建了配置快照。
- 补丁后验证通过。
- 验证失败,因此我已回滚到已知良好的配置。
错误做法
- - 直接编辑配置而不做快照
- 因为写入完成就认为文件没问题
- 在解析错误或缺少代理引用后继续操作
注意事项
此技能不会持续运行。它是针对高风险配置操作的按需防护栏。
每当配置完整性比速度更重要时,请使用它。
如果你即将修补或重写配置,并且想跳过快照步骤,那正是你不应该跳过的时候。
总结
配置哨兵通过结合以下功能使OpenClaw配置变更更安全:
目标很简单:
让配置编辑可恢复,而非灾难性。