OpenClaw landed a cluster of exec-boundary fixes today: PR #102035, "fix: bind package-manager exec approvals to inner commands", PR #101353, "fix: detect joined inline eval flags", and PR #102032, "Harden jq safe-bin semantics".
The shared theme is durable trust. When an operator marks a local command as safe or always allowed, OpenClaw has to make sure that approval does not accidentally cover a broader command shape later.
Package Managers Now Bind to Inner Commands
PR #102035 fixes a package-manager wrapper approval issue. Operators could approve a wrapped exec command as always allowed, but the durable approval could attach to the wrapper rather than the effective inner command.
The change routes package-manager exec wrappers through the same dispatch-wrapper trust planning used by other command carriers. Supported direct forms bind approval policy to the inner command, while shell-call package-manager forms stay one-shot instead of creating reusable allow-always patterns.
That means common package-manager exec workflows can continue, but a durable approval should no longer broaden trust to later wrapped shell payloads.
Inline Eval Detection Catches Joined Flags
PR #101353 tightens inline-code detection for interpreters and runtimes. The issue was that joined eval flags could look different from separated flag/value forms, even though they trigger the same kind of inline execution.
OpenClaw now recognizes glued single-letter eval flags such as -c... and equals-joined long eval flags such as --eval=.... Unrelated multi-letter flags remain exact-only unless their spec declares a prefix form.
For users with interpreter or runtime binaries in an allowlist, this makes strict inline-eval hardening apply consistently across both separated and joined flag forms.
jq Leaves Safe Bins
PR #102032 changes how OpenClaw treats jq in tools.exec.safeBins. Safe bins are intended for narrow stdin-oriented tools whose behavior can be constrained. The PR argues that jq is broader than that model because it can read environment data and load code through modules and startup files.
The result: jq no longer qualifies for approval-free safe-bin execution. Operators can still run it through an explicit trusted-path allowlist entry or through the normal approval prompt.
Doctor and security audit now warn about risky jq safe-bin entries rather than scaffolding profiles that cannot satisfy the runtime semantic gate.
Why It Matters
Exec controls are one of OpenClaw's sharpest boundaries. Small parser differences can matter when a user expects "allow this" to mean a narrow command, not a family of future payloads.
This set of PRs closes three practical gaps:
- Package-manager approvals bind to the inner command instead of the wrapper.
- Joined eval flags are treated like separated eval forms.
jqis removed from the approval-free safe-bin model.
Each change preserves an explicit path for trusted use. What changes is the default treatment of ambiguous or broad command shapes.
Validation
PR #102035 reports 89 focused tests across wrapper trust planning, allow-always persistence, exec approvals, and node-host run planning.
PR #101353 reports 48 tests for inline eval analysis and exec authorization allowlists.
PR #102032 reports 227 tests across safe-bin semantics, policy, approvals, runtime policy, Doctor integration, security audit, and approval config behavior. It also includes current-head behavior proofs showing unsafe jq module and environment probes denied as safe-bin matches, while explicit /usr/bin/jq allowlisting and simple head safe-bin behavior still work.
Bottom Line
OpenClaw is tightening exec approval semantics where wrapper commands, interpreter flags, and broadly capable utilities can blur the meaning of "safe." For operators, the safest reading is also the simplest one: durable approvals should apply to the command that will actually run, and broad command surfaces should stay explicit.