Problem

OpenClaw currently has a hard boundary around some protected config paths when changes are initiated from inside an agent session. That boundary is good in spirit: an agent should not be able to silently or autonomously grant itself more authority.

But the current implementation creates a sovereignty problem for owner-operated deployments: even when the human owner explicitly asks and confirms in chat, the agent has no valid approval path for protected changes such as enabling the /mcp command or registering an MCP server. The only available outcomes are:

1. refuse the owner request, or
2. bypass the OpenClaw config tool by raw-editing openclaw.json, which normalizes exactly the wrong precedent.

That is the wrong tradeoff. The system should preserve the guardrail while giving the owner a first-class, auditable approval path.

Concrete example

Goal: register a locally installed MCP server after auditing/smoke-testing it.

The owner tried to run:

/mcp set agentic-aqua={"command":"/Users/senemaro/.local/bin/aqua-mcp","args":[]}

OpenClaw replied:

⚠️ /mcp is disabled. Set commands.mcp=true to enable.

The agent inspected the schema and confirmed:

commands.mcp: boolean
Allow /mcp chat command to manage OpenClaw MCP server config under mcp.servers (default: false).

Then the agent attempted the sanctioned config path:

{"commands":{"mcp":true}}

Gateway refused:

gateway config.patch cannot change protected config paths: commands.mcp

This left no legitimate agent-mediated owner approval flow. The owner explicitly authorized the change, but OpenClaw still forced the choice between human manual editing and agent-side bypass.

Why this matters

This is not a request to let agents freely self-escalate.

It is the opposite: owner-approved escalation should be explicit, structured, logged, and harder to confuse with autonomous agent behavior.

Right now, the hard block makes the safe path unavailable. A capable owner can still edit the file directly, but then OpenClaw loses the chance to:

• show the exact diff before approval,
• require an explicit human confirmation gesture,
• restart/reload safely,
• record an audit trail,
• distinguish owner intent from agent initiative,
• apply extra checks for dangerous MCP servers or command flags.

For local-first/open-source deployments, sovereignty means the owner can authorize changes to their own machine without teaching the agent to step around the runtime boundary.

Current implementation clue

The gateway tool appears to allow only a small allowlist of config paths for agent-side mutation and rejects others as protected.

Observed in the installed build:

const ALLOWED_GATEWAY_CONFIG_PATHS = [
  "agents.defaults.systemPromptOverride",
  "agents.defaults.promptOverlays",
  "agents.defaults.model",
  "agents.defaults.thinkingDefault",
  "agents.defaults.subagents.thinking",
  "agents.defaults.reasoningDefault",
  "agents.defaults.fastModeDefault",
  "agents.list[].id",
  "agents.list[].systemPromptOverride",
  "agents.list[].model",
  "agents.list[].thinkingDefault",
  "agents.list[].subagents.thinking",
  "agents.list[].reasoningDefault",
  "agents.list[].fastModeDefault",
  "channels.*.requireMention",
  "channels.*.*.requireMention",
  "channels.*.*.*.requireMention",
  "channels.*.*.*.*.requireMention",
  "channels.*.*.*.*.*.requireMention",
  "messages.visibleReplies",
  "messages.groupChat.visibleReplies"
];

And:

if (disallowedPaths.length > 0) {
  throw new Error(`gateway ${params.action} cannot change protected config paths: ${disallowedPaths.join(", ")}`);
}

That hard error is the core UX/security problem: it treats all protected edits as impossible from the agent path, even with live owner confirmation.

Proposed fix: owner-approved protected config changes

Add a first-class approval flow for protected config mutations instead of hard-failing immediately.

Suggested behavior:

1. Agent calls gateway config.patch or a new action such as gateway config.propose.
2. Gateway computes the exact changed paths and classifies risk:
   • normal allowlisted path → current behavior
   • protected path → requires owner approval
   • dangerous path/flag → requires stronger approval or remains blocked depending on policy
3. Gateway returns an approval card to the current human/operator surface showing:
   • exact config path(s), e.g. commands.mcp
   • old value and new value
   • full JSON patch/diff
   • risk label and explanation
   • whether restart is required
   • requesting agent/session identity
4. Human explicitly approves via the native approval UI or an owner-only command.
5. Gateway applies the change itself, writes an audit record, and restarts/hot-reloads as needed.

Specific MCP handling

For MCP-related paths, add extra review fields:

• command path
• args
• environment variables/secrets referenced
• cwd
• whether command is absolute or PATH-resolved
• whether executable exists
• package provenance if known
• tool list if the server can be smoke-tested before enabling
• warning if tools include destructive/financial actions

Example approvals that should be possible:

{"commands":{"mcp":true}}

and later:

{
  "mcp": {
    "servers": {
      "agentic-aqua": {
        "command": "/Users/senemaro/.local/bin/aqua-mcp",
        "args": []
      }
    }
  }
}

Safety requirements

This should not become a blanket escape hatch.

Recommended constraints:

• default deny for protected paths unless an explicit owner approval arrives;
• approvals expire quickly;
• approval must include exact patch hash/base config hash to prevent TOCTOU surprises;
• approval should be bound to the requesting session and patch contents;
• dangerous flags may require typed confirmation or config-level opt-in;
• all protected approvals should be logged in an audit trail;
• channel identity should matter: group chat confirmation should be treated differently from a local TUI or authenticated owner DM;
• optional config policy could disable this feature entirely for hosted/shared deployments.

Why this is better than the current state

The current state is neither fully safe nor sovereign:

• It blocks legitimate owner-directed work through the sanctioned tool.
• It pressures users toward manual edits or alternate agents.
• It gives agents an incentive to consider raw file bypasses.
• It provides no structured diff, approval, or audit trail for the actual change.

A protected-edit approval flow would make the safe thing also the easy thing.

Acceptance criteria

• An agent can propose a protected config change without applying it.
• The owner sees an exact diff and risk explanation.
• The owner can approve or deny through a first-class OpenClaw mechanism.
• Approved changes are applied by Gateway, not by raw agent file editing.
• The approval is logged with session/agent/path/old/new metadata.
• Existing hard-block behavior remains available via config policy for deployments that want it.
• The MCP registration flow works without requiring manual openclaw.json edits when owner approval is present.