OpenClaw Relays Claude Native Tool Requests Into Gateway Approvals

OpenClaw has merged an interactive approval relay for Claude CLI’s native and extension tools. Under restrictive execution policy, requests that previously failed silently can now appear through the Gateway’s existing approval flow.

This makes Claude’s own Bash, WebFetch and browser-extension tools usable without switching the whole session to YOLO policy. It also expands what an operator may be asked to authorize, so the safe adoption question is not merely whether prompts appear—it is whether each decision is scoped tightly enough.

The operator decision

• If you currently use restrictive Claude CLI sessions: wait for a release containing PR #112918, then test one harmless native-tool request end to end.
• Do not enable YOLO to work around silent denial. The relay exists specifically to preserve human review under restrictive policy.
• Treat browser credential tooling as privileged. Never send passwords or one-time codes through chat, and verify the browser/session prerequisites before allowing credential autofill.
• Keep Bash one-shot. The merged design deliberately refuses an “allow always” grant for Bash because a tool-name-only grant would amount to unrestricted command execution.

What changed

OpenClaw already starts Claude Code with a standard-I/O permission prompt tool. Its handler previously had binary behaviour: allow under YOLO policy, deny otherwise. A restrictive policy therefore had no human-in-the-loop path for Claude-native tools.

PR #112918 routes approval-required requests through the existing two-phase Gateway broker: request a decision, then wait for the result. It does not introduce a separate approval store or transport.

The result maps policy states deliberately:

• security: deny remains an immediate denial;
• YOLO remains an immediate allow;
• ask: off does not prompt and preserves allowlist denial behaviour;
• ask: always prompts every time and does not reuse grants; and
• eligible “allow always” decisions are limited to the tool name and live only for the Claude process lifetime.

Timeouts, aborted runs, unreachable approval routes and Gateway outages deny fail-closed.

Bash gets stricter treatment

A persistent grant for a benignly named browser tool can still be powerful, but a persistent grant for Bash would be effectively unlimited execution because the tool name says nothing about later command arguments.

The merged implementation therefore never offers Bash an allow-always path. Oversized Bash input also fails closed and asks the caller to split and retry rather than showing a misleading truncated command with a reusable decision.

Long approval descriptions use head-and-tail display with an explicit hidden-size marker. Only one-shot decisions are available where truncation prevents the operator from seeing the complete request.

Interpretation: an approval interface is part of the authorization boundary. If the UI cannot faithfully display what will execute, persistence is unsafe.

Browser and 1Password implications

The upstream change was motivated partly by Claude browser tools, including the 1Password for Claude credential-autofill path. OpenClaw preserves Chrome passthrough for normal runs while restricted runs continue forcing the documented safer browser posture where applicable.

Credential autofill should not become credential relay. The human should complete sensitive authentication in the trusted browser surface; the model transcript should not contain passwords, recovery codes or one-time codes.

Before enabling browser tools, verify:

1. which browser profile the Claude process controls;
2. which sites are already authenticated;
3. whether the current requester is allowed to invoke the tool;
4. what exact action is visible in the approval card;
5. whether the resulting tool can access unrelated tabs or credentials; and
6. how denials and timeouts appear in both the chat and audit trail.

Test the policy, not just the happy path

Use a disposable Claude session and harmless requests to prove:

• an allow-once decision permits only that request;
• ask: always prompts on a second invocation;
• ask: off does not create a surprise prompt or bypass;
• Bash never offers a reusable blanket grant;
• cancelling the run denies the waiting tool;
• disconnecting the approval route fails closed; and
• restarting Claude clears process-scoped reusable grants.

Also test the delivery channel where operators will actually make decisions. A Gateway generating an approval is not enough if the intended person never sees it.

Evidence and limits

Upstream reports 21 focused relay tests, 101 CLI-runner spawn tests, 46 Anthropic extension tests and repeated structured review. The cited cases include allow-once, allow-always reuse, ask-always re-prompting, oversized Bash rejection, abort propagation and unavailable approval routes.

OpenClaw Academy reviewed the official merged pull-request body and chronology. We did not connect Claude in Chrome, invoke 1Password or independently exercise a live Gateway approval. Behaviour and test results are attributed to upstream evidence.

Bottom line

This merge fixes the wrong trade-off. Operators should not have to choose between “Claude’s native tools never work” and “everything runs without review.”

Once the change reaches your deployment, keep restrictive policy, test the relay through the real channel and scrutinize persistent decisions. Human approval is useful only when the human can see the actual capability being granted.