Two OpenClaw Exec-Approvals Repairs Close a Token Leak and Zombie Policies

Two merged changes on August 21, 2026 repair how OpenClaw handles exec-approvals state — the local policy store that decides which shell commands an agent may run without asking. One leaked a live credential through routine CLI output; the other let deleted agents keep speaking through their old policies.

The approvals CLI printed its socket token

PR #127610 fixes a discrepancy between the two output modes of the approvals commands. openclaw approvals get --json — and the --json mode of every local approvals write such as approvals allowlist add and approvals set — printed the exec-approvals socket record including the bearer token in cleartext, while the human-readable table for the same command showed only the socket path. Machine-readable and human output disagreed about a secret, and the secret lost.

Anything that captures CLI stdout therefore captured a working credential for the exec-approvals socket: CI logs, shell history, terminal scrollback, paste-to-support transcripts, error reporters.

The merged fix aligns the JSON output with the table view so the token no longer appears in command output.

Interpretation: this is a secrets-hygiene fix in the classic sense — the credential itself was not weakened, but its disclosure surface shrank from “anyone who can read your logs” to “whoever can read the socket file.” Treat the two as very different exposure classes.

Operator actions

1. Inventory where approvals command output is retained: CI logs, dotfiles, support tickets, chat paste-ins. Anything captured before upgrading should be treated as containing a live socket token.
2. After upgrading to a containing build, rotate the socket credential using OpenClaw’s supported mechanism so captured copies become inert.
3. Grep stored logs for the socket path pattern as a cheap triage for where the token may have landed alongside it.

Removed Claw agents left their approval policies behind

PR #127365 fixes a lifecycle gap in openclaw claws remove <agent>. The command deleted the agent and reported agentRemoved: true — but the agent’s exec-approvals policy stayed in the shared state database, keyed by the raw agent id.

Because policy lookup goes through that same id, the next agent created with a recycled id silently inherited the removed agent’s approval rules. A fresh agent could start life with an allowlist its operator never granted it.

The merged fix removes the exec-approvals policy as part of agent removal, so removal means removal.

Interpretation: the practical risk depends on id reuse, which is uncommon but normal in scripted environments that create and destroy agents by name. Fleets that provision agents programmatically are the population that should care.

Operator actions

1. After upgrading, audit the shared state for approval policies belonging to agents that no longer exist; clean up any stragglers from pre-fix removals.
2. If you recycle agent ids in automation, re-check the effective approval policy of any agent created shortly after another was removed on an affected build.
3. Add an assertion to provisioning scripts: a newly created agent must start with the policy you intend, not whatever its predecessor had.

Why these belong together

Both defects share a shape: approvals state outlived or escaped its owner. One escaped into command output; the other outlived the agent that owned it. Neither required a remote attacker — ordinary operational habits (logging output, recycling ids) were enough to make them matter.

Upstream rated both fixes at its highest attention tiers, with the token-leak fix carrying a platinum-tier review rating. These are upstream assessments; OpenClaw Academy reviewed the official merged records and did not independently execute the proofs.

Bottom line

If your automation reads --json output from approvals commands, or your fleet creates and removes agents under repeated ids, pull a containing build forward on your normal upgrade cadence and do the two audits above. Both fixes are behavior repairs with no configuration surface — the safe posture is simply to assume pre-fix output and pre-fix removals were contaminated until checked.