Two OpenClaw Trust-Boundary Fixes Land on Main: Exec Approvals and Discord History

Two merged OpenClaw fixes tighten boundaries operators may reasonably have treated as stronger than they were:

1. a reusable approval for one direct executable command could be reused with different arguments on POSIX hosts; and
2. Discord’s allowlist-based contextVisibility could still include pending room history from other senders.

Both fixes are on main. Neither is in the current npm latest or beta package at verification time.

This is not an upstream security advisory with a published affected-version matrix. It is enough evidence for cautious interim controls, not enough to invent a CVE, exploitability rating or universal emergency-upgrade claim.

What operators should do now

If you use reusable exec approvals

Until a package explicitly includes PR #112946:

• prefer one-time approval for commands where arguments control destinations, files, credentials, permissions or side effects;
• review persisted allow-always rules and remove broad entries you no longer need;
• do not assume approving one invocation of an executable constrains all later invocations to the same arguments; and
• keep tool policy and sandboxing in place—approval is one layer, not the whole execution boundary.

If you use Discord sender-scoped context visibility

Until a package explicitly includes PR #113407:

• do not treat allowlist-based context visibility as a hard confidentiality wall between participants in a shared room;
• avoid placing sensitive cross-user material in rooms where the agent keeps pending history;
• separate trust zones into different rooms or sessions where practical; and
• test both quoted context and recent pending history after upgrading.

The default Discord visibility mode is all and remains intentionally unchanged. The bug matters specifically to operators who selected a stricter mode and expected sender-based filtering.

Fix one: reusable approval now binds the arguments

PR #112946 says a reusable approval for a specific host executable command could previously match the same executable with different arguments on POSIX systems.

That distinction is security-relevant. The executable path alone often says very little about the effect:

curl <approved-destination>
curl <different-destination>

The merged fix persists a generated argument pattern for direct executables on every platform. POSIX rules bind the approval to the exact approved argument tokens; Windows retains its path-separator normalization. A later invocation with changed arguments should require a fresh decision.

The upstream regression test uses exactly this class of case: an approved direct curl invocation remains reusable for its original argument vector but not for a different one.

Interpretation: “allow always” should mean “allow this reviewed command shape,” not “trust this binary to do anything.” The fix aligns persistence with that safer mental model.

Fix two: Discord pending history gains sender provenance

PR #113407 addresses a different kind of authorization drift. Discord operators can configure stricter context visibility, but pending in-memory room history from other senders could still reach the model prompt and structured inbound history.

The merged change snapshots stable sender provenance when each history entry enters the in-memory window, then applies the selected visibility mode consistently to prompt and inbound history.

This is about model-visible context, not only what the bot prints back. Material from another sender reaching the prompt can influence a response or tool decision even when it is never quoted verbatim.

Upstream reports Discord preflight, room-event and context suites passing, including a disabled-history regression test. We have not independently replayed a multi-user Discord room against the patch.

Requester controls do not authenticate surrounding content

A same-day documentation change, PR #113400, makes the wider lesson explicit: controls such as toolsBySender, sender ownership and owner-only tool inventories bind the requester who originated the current turn.

They do not authenticate every item supplied to the model. Quoted messages, shared history, forwarded or fetched content and attachments remain untrusted content even when the current requester is authorized.

That means the Discord history fix should not be read as a general prompt-injection cure. It narrows which history enters a sender-scoped context. Operators must still design tool permissions so hostile content cannot borrow the requester’s authority.

Release boundary

At verification time, npm reported:

• latest: 2026.7.1-2
• beta: 2026.7.2-beta.4

Beta.4 was published at 06:11 UTC on 24 July. The exec-approval fix merged at 10:08 UTC and the Discord history fix at 21:27 UTC, so chronology alone rules both out of that package.

Do not use “merged” as a substitute for checking release contents. Watch for the pull-request numbers or merge commits in a later release, then verify the installed version before relaxing interim controls.

Evidence and limits

OpenClaw Academy verified the merged pull requests, commit timestamps and changed-file surfaces through GitHub’s API, plus current npm distribution metadata. We did not construct a vulnerable host-command flow, connect a Discord test bot or establish a complete affected-version range.

The safe claim is narrow: the current official npm channels predate fixes for the behaviours described by upstream. Operators relying on those boundaries should compensate until a package explicitly carries the patches.

Bottom line

These fixes share one lesson: scope must attach to the thing an operator actually approved.

For exec, that means the executable and its arguments. For Discord, it means the sender provenance of history entering a scoped context. Until the fixes ship, use one-time approvals for argument-sensitive commands and do not rely on Discord context visibility as cross-user confidentiality isolation.