[MXC][RFC] Add per-tool sandbox configuration by ChazGo · Pull Request #1 · ChazGo/rfcs

ChazGo · 2026-07-21T21:35:38Z

Why is this change being made?

OpenClaw currently applies one shared MXC baseline to MXC-backed execution, but
different tools and argument sets can require narrower access. We need a
user-controlled per-tool layer without replacing the existing per-agent sandbox
settings or shared MXC baseline configuration.

We also need an application-owned workflow for consuming MXC denial capture.
MXC returns denial records after the process exits, so OpenClaw must validate
those records, present an approval decision, and rerun only when the requested
change remains within the existing configuration limits.

IMPORTANT NOTE: This is a significant iteration on the existing RFC, not a new
proposal. The per-tool configuration advisor, exact and wildcard matching,
SQLite storage, MXC execution boundary, CLI management, and compatibility
behavior remain recognizable. The main review areas are the
ContainerConfig-shaped sandbox configuration fragment, Learning Mode, and the
clarified Gateway and Windows Node boundary.

What changed?

Replaced the OpenClaw-specific sandbox envelope with an MXC
ContainerConfig-shaped sandbox configuration fragment.
Clarified how per-tool configurations compose with resolved per-agent
settings and the shared MXC baseline configuration.
Required per-tool configurations to restrict both existing configuration
surfaces rather than add grants.
Kept the per-tool wildcard scoped to all argument sets for one named tool.
Added MXC app/user-configurable block mode with Deny, Allow once, and
Always allow rerun behavior.
Added MXC fleet-auditing allow mode for explicitly initiated, reduced-
containment observation and reviewed configuration proposals.
Required denials that exceed the agent or MXC baseline configuration to be
handled as baseline changes instead of per-tool changes.
Documented how the stored fragment can add future MXC fields through explicit
composition, schema validation, and migration rules.
Added the MXC Node SDK dependency requirements for typed capture
configuration, structured output metadata, runtime support, and completeness.
Kept Gateway-local and Windows Node configurations separate while allowing
Windows Node to adopt the same per-tool matching and Learning Mode workflow.

What changed since the previous review?

Preserved the existing per-agent and shared MXC baseline configuration
surfaces.
Changed per-tool composition from additive grants to restrictive sandbox
configuration.
Added both MXC captureDenials modes and post-exit approval.
Clarified that Windows Node can adopt the design with separate node-local
configuration and enforcement.

How was the change tested?

Validated Markdown whitespace and structure.
Reviewed the RFC against the current OpenClaw MXC baseline implementation and
MXC denial-capture contract.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 03153551-136c-49df-a726-242cd03f26a4

MythiliMur · 2026-07-22T00:38:26Z

No need to talk about “session-wide” in description

MythiliMur · 2026-07-22T00:40:42Z

+
+## Motivation
+
+OpenClaw currently applies a sandbox policy at a broader session or backend


Policies are already applied per tool, no? How does this interact with existing policy config file?

The existing MXC policy provides a default policy config applied to every MXC-backed call. This proposal adds stored policies for specific tools or arguments. I'm updating the RFC to explicitly state how the per tool policies will interact with the default policy.

MythiliMur · 2026-07-22T00:44:19Z

+- Allow settled policies to proceed without prompting.
+- Prompt for an operator decision when a matching policy is still in
+  development.
+- Persist mutable policy state in OpenClaw's SQLite state database.


Do we need to guarantee that openclaw itself is not able to modify these files during runtime without user intervention?

OpenClaw needs trusted runtime access to update policy lifecycle and usage metadata. The guarantee should be that MXC-backed tool execution cannot modify the policy store directly. Policy changes should only occur through the MXC plugin and supported operator management paths

MythiliMur · 2026-07-22T00:50:17Z

+
+## Goals
+
+- Evaluate tool calls against local policy before execution.


Requested policy is a union of policy settings as configured by gateway admins and per tool policy from policy store. Please update the design accordingly.

The next iteration I'm sending out will more explicitly state how the default policy applied to every tool will be composed with the per tool policies.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1255dade-bf9b-4463-8c58-52c3470abff8

ChazGo · 2026-07-22T20:48:47Z

No need to talk about “session-wide” in description

Idk how to directly reply to this but agree session is overloaded term here. Going to rephrase. The session-wide meant the chat session (i.e. the existing default policy that can be set which applies to every single tool call)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: de39d8d8-c02d-4bc5-a0ca-b15a964b2493

ChazGo · 2026-07-30T21:42:06Z

+
+## Goals
+
+- Select a sandbox configuration for each OpenClaw tool call.


Open question on per agent, per tool sandbox configurations

Updated the RFC to clarify this. Per-tool sandbox configurations are stored globally, not per agent, but they are composed with the invoking agent’s resolved sandbox settings and cannot widen that agent’s access

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: e7b77e58-db8b-4dea-a202-b2d397478725

MythiliMur · 2026-08-18T18:27:33Z

+
+### Ownership
+
+The MXC plugin registers a low-priority `before_tool_call` hook. Ordinary hooks


Registers only when MXC plugin is enabled right?

Yes. The hook is registered only when the MXC plugin is enabled. I’ll make that explicit.

MythiliMur · 2026-08-18T18:30:03Z

+- Keep configuration selection and MXC enforcement in the OpenClaw MXC plugin.
+- Support exact and per-tool wildcard configuration matching.
+- Allow calls with no matching configuration to preserve existing behavior.
+- Persist mutable per-tool sandbox configurations in OpenClaw's SQLite state


is this openclaw sqlite corrupt free from both the tools & models / orchestration / agent loop?

Sandboxed tool processes cannot access the OpenClaw state directory, and the model has no direct database access. Writes go through the trusted MXC plugin using OpenClaw’s validated plugin-state API rather than direct SQLite access.

The OpenClaw host and trusted plugin code necessarily retain access to manage the entries. Store read, parse, or corruption errors fail the governed tool call closed

richiemsft · 2026-08-18T22:05:21Z

+operation; OpenClaw starts a new tool execution. A denial that requires
+changing the shared baseline or per-agent settings is reported as a baseline
+configuration change instead of a per-tool change. OpenClaw will not persist
+the denial document, ETL, raw events, or a separate learning session.


App caller is responsible for deleting the json files.

Thanks, I’ll make that lifecycle explicit.

OpenClaw will read and validate the per-run denial JSON after the process exits, retain only the reviewed configuration result in memory or SQLite, and delete the raw JSON on every terminal path. ETL retention will remain disabled, and OpenClaw will clean up any reported retained artifact if one is produced.

ChazGo · 2026-08-20T21:51:54Z

+applies to all argument sets for that tool. Configurations are shared across
+agents but are composed with the invoking agent's resolved sandbox settings.
+
+### Sandbox configuration fragment


@asklar @richiemsft I'm not sure if SandboxPolicy would be better for OpenClaw to store and then call createConfigFromPolicy(). SandboxPolicy seems better for cross platform usage but it seems like it's missing platform specific fields that ContainerConfig includes.

Any recommendations for SandboxPolicy or storing a ContainerConfig fragment?

That must be a gap, @bbonaby, @theelliotm

docs: propose MXC per-tool policy advisor

d6969b0

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 03153551-136c-49df-a726-242cd03f26a4

MythiliMur reviewed Jul 22, 2026

View reviewed changes

Comment thread rfcs/0026-mxc-per-tool-policy-advisor.md Outdated

MythiliMur reviewed Jul 22, 2026

View reviewed changes

docs: clarify MXC policy composition

4d1d6d1

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1255dade-bf9b-4463-8c58-52c3470abff8

ChazGo marked this pull request as ready for review July 22, 2026 20:49

docs: revise MXC per-tool sandbox configuration

836d77a

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: de39d8d8-c02d-4bc5-a0ca-b15a964b2493

ChazGo changed the title ~~docs: propose MXC per-tool policy advisor~~ [MXC][RFC] Add per-tool sandbox configuration Jul 29, 2026

ChazGo mentioned this pull request Jul 30, 2026

feat(mxc): add per-tool sandbox configuration openclaw/openclaw#116428

Closed

ChazGo commented Jul 30, 2026

View reviewed changes

docs: add Learning Mode to MXC sandbox RFC

9310748

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: e7b77e58-db8b-4dea-a202-b2d397478725

MythiliMur reviewed Aug 18, 2026

View reviewed changes

richiemsft reviewed Aug 18, 2026

View reviewed changes

ChazGo commented Aug 20, 2026

View reviewed changes


		## Motivation

		OpenClaw currently applies a sandbox policy at a broader session or backend


		## Goals

		- Evaluate tool calls against local policy before execution.


		## Goals

		- Select a sandbox configuration for each OpenClaw tool call.


		### Ownership

		The MXC plugin registers a low-priority `before_tool_call` hook. Ordinary hooks

Conversation

ChazGo commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why is this change being made?

What changed?

What changed since the previous review?

How was the change tested?

Uh oh!

MythiliMur commented Jul 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ChazGo commented Jul 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ChazGo commented Jul 21, 2026 •

edited

Loading