OpenClaw Ops

Safe, documented, schema-validated gateway configuration operations.

When to Use

• Any interaction with openclaw.json: read, analyze, modify
• config.get, config.schema.lookup, config.patch, config.apply
• Adding/removing models, plugins, channels, agents, MCP servers, tools config
• Troubleshooting config validation errors
• Analyzing current config for optimization opportunities

Two Modes

Determine mode before starting any config work.

Mode A: Analysis Only (no config change)

Trigger: user asks to check, review, compare, optimize, or analyze config, without providing a specific target value.

Flow:

1. config.schema.lookup for relevant keys
2. Official doc verification (see Step 2)
3. Present findings with schema + doc evidence
4. Stop. Wait for user instruction.

Output format:

## Config Analysis

**Finding**: what was found
**Current state**: relevant config values (from config.get)
**Schema evidence**: what schema.lookup confirmed
**Doc evidence**: source URL or QMD reference
**Recommendation**: suggested change (if any), or "no action needed"

Transitioning to Mode B: if user responds with explicit approval to execute a recommended change (e.g. "do it", "apply", "yes, modify it"), switch to Mode B. Start from Step 3 (Form Change Proposal) — Steps 1 and 2 evidence from Mode A can be reused.

Mode B: Modification (config change)

Trigger: user explicitly requests a change AND provides sufficient detail (target key + intended value or clear intent). Examples:

• "add model X with id Y"
• "set thinkingDefault to medium"
• "remove the minimax plugin"
• Responding to a Mode A recommendation with "do it" / "apply" / "确认修改"

Insufficient for Mode B (fall back to Mode A + ask):

• "帮我改一下配置" without specifying what to change
• "优化一下" without target values
• Vague instructions without concrete config keys or values

Flow: all 6 steps below, in strict order. No step may be skipped.

Mode Switching Rules

Mandatory Process — Mode B (6 Steps)

Step 1: Schema Lookup

config.schema.lookup(path="target.config.key")

Verify:

• Key exists in schema (not invented)
• Type matches intended value
• enum values present → only use values from the enum
• additionalProperties: false → no extra sub-fields allowed
• Free-form objects (additionalProperties: {}) → still verify field names from docs

Schema has key + config doesn't: this means the key can be created. Proceed to Step 2. Schema lookup fails or key doesn't exist: STOP. Do not proceed. Report to user.