OpenClaw Exec Approvals Just Got Teeth: Cwd-Bound Reusable Approvals, Scoped Cron Grants, and Revocable MCP App Access

Three changes merged on OpenClaw main between the evening of 2026-08-25 and early 2026-08-26 (UTC) rework how long-lived approvals hold their authority. One has a direct operator to-do attached; the other two change behavior you should understand before your next approval prompt. Together they point the same direction: durable approvals are being narrowed from “this command is allowed” toward “this command is allowed, here, for this job, until revoked.”

The breaking one first: reusable approvals are now bound to a working directory

PR #129636 (merged 2026-08-26 01:24 UTC) fixes an issue where a reusable exec approval generated from one approval prompt could be reused for the same command and arguments from a different working directory — meaning a command could operate on files the operator never saw when approving. Generated approvals now bind the canonical working directory and exact argument vector in a single cross-platform sha256:cwd-argv:v1 format shared by Node and the macOS host.

The operator-visible consequences, straight from the PR:

• New reusable prompts say Always allow here and show the directory that will be trusted.
• Older argv-only generated approvals become inactive after upgrade. This is the breaking part: if you relied on generated reusable approvals, expect fresh prompts after upgrading.
• openclaw doctor --fix removes only those inactive generated entries; manual allowlist rules and current cwd-bound generated rules remain unchanged.

Recommended sequence:

1. Upgrade to a build containing #129636.
2. Run openclaw doctor --fix to clear deactivated generated entries.
3. Re-run your routine commands once each in their intended directory and choose Always allow here when prompted.

The maintainers report packaged behavior proofs on Windows 11 and macOS showing same-cwd authorization succeeding while other-cwd reuse fails closed; those are their claims from the PR evidence section, not independently reproduced by this desk.

Interpretation: this closes a real trust-boundary gap — the operator reviewed a command in a context, and only the context makes the review meaningful. It also quietly retires a convenience. If your automation depended on one generated grant serving many directories, that pattern is gone by design.

Recurring cron automations can finally be approved — narrowly

PR #129526 (merged 2026-08-25 23:17 UTC) addresses a long-standing dead end: a scheduled command under ask exec policy could never run, because cron runs cannot answer interactive prompts. A prior change (#128031) had suppressed cron approval delivery entirely, so the scheduled job just auto-denied forever unless you hand-edited the allowlist. Worse, resolving a cron approval with Allow always used to write an unbounded command digest into the JSON allowlist — a permanent, job-independent grant that survived job edits and deletion.

The new mechanism, per the PR:

• Resolving Allow always on an approval raised by a cron job’s isolated run mints a scoped standing grant in a dedicated SQLite table, bound to the exact agent, cron job, job config revision, and operation (command text, cwd, env hash) — inside the same transaction that resolves the approval. No more unbounded JSON-allowlist digests for cron approvals.
• Later occurrences of the same job execute that exact operation without prompting. Every use revalidates against authoritative rows and fails closed: 30-day expiry, revocation, job edits or deletion (config revision mismatch), or loss of the original allow-always resolution all fall back to a normal prompt path.
• Mutable file operands, heredocs, strict inline eval, and audit-suppression approvals keep prompting per occurrence.
• Cron approval requests now reach connected approval surfaces (Control UI, TUI) without spamming chat channels; with no client connected, requests expire into the existing headless denial.
• Non-cron approvals are unchanged.

What this means in practice: recurring automation under ask policy becomes usable without granting permanent power. The grant is exactly as wide as the job, dies with the job, expires in 30 days, and every use re-checks itself. Interpretation: this is the difference between “approve once, forever, globally” and “delegate this specific task.” If you have been avoiding scheduled jobs because approval policy forced you into either auto-denial or permanent allowlisting, this changes the calculus.

MCP App resource access now actually stops at revocation

PR #129550 (merged 2026-08-25 21:04 UTC) fixed an issue where an MCP App view could continue listing or reading resources from its owning server after the view’s App-interaction authority was revoked — including results of a read request already in flight at revocation time. Resource list, template-list, and read operations now share one Gateway-owned authority boundary that validates the current App grant before starting upstream work and again before returning results. Views lacking initial authority no longer advertise the server-resource capability; already-rendered views stay mounted but receive an explicit denial instead of being torn down.

Initial ui:// document rendering, view/ticket lifetimes, and native Codex MCP App bindings are intentionally unchanged. Legitimately authorized Apps keep existing workflows. The maintainers’ evidence includes real Gateway lifecycle E2E (allowed read before removal, denied through the same still-valid ticket afterward) and a real Chromium E2E covering live revocation with a stale capability snapshot; again, maintainer-reported.

Operator takeaway: revoking an MCP App’s grant now behaves like an operator expects — access stops, including mid-flight reads. If you audit MCP App grants as part of offboarding or incident response, post-upgrade behavior finally matches what your runbook assumed all along.

The common thread, labeled as analysis

None of these three changes shipped as numbered releases or advisories in this window; they landed directly on main. The direction across them is consistent: approvals and grants must carry their full context — directory, job identity, config revision, liveness — and must die when that context dies. For operators the rule of thumb going forward: treat any approval that survives context changes as suspect, and expect OpenClaw to keep narrowing exactly those.

Verification status

This desk verified all merge records, pull-request bodies, and commit SHAs from captured primary-source data (GitHub API payloads collected deterministically into the editorial intel database). Behavior descriptions come from the PRs’ own documentation sections; maintainer test claims are reported, not independently re-run. No CVE numbers or GitHub Security Advisories accompanied these merges at verification time.