A Tiny /usr/bin/time Detail Turned OpenClaw’s Exec Allowlist into a Liability

Execution safety is full of fake comfort. Teams say a command runner is safe because it has approvals, an allowlist, a wrapper, or a sandbox, then act surprised when the real bug turns out to be path resolution. OpenClaw’s GHSA-qm9x-v7cx-7rq4 advisory is a clean example of the category. The flaw was not “agents can run dangerous commands,” which everyone already knows. It was that allow-always approvals did not unwrap /usr/bin/time, which meant an unregistered time wrapper could reuse approval state for a different inner executable. Tiny detail, large consequence.

According to the GitHub advisory, affected version 2026.3.22 failed to normalize that wrapper in the allow-always approval path. The result was an allowlist bypass in system.run approvals: the user or policy could think it had approved one executable, while the system ultimately let a different inner command piggyback on that approval. The fix landed in commit 39409b6a6dd4239deea682e626bac9ba547bfb14, which updates src/infra/dispatch-wrapper-resolution.ts to unwrap /usr/bin/time and bind approvals to the actual inner executable. Regression coverage was added in src/infra/exec-approvals-allow-always.test.ts, and the patch shipped in v2026.3.22 and remains present in v2026.3.23 and v2026.3.23-2.

VulnCheck describes the issue as an incorrectly resolved name or reference problem, with a 7.7 CVSS v4 score. That taxonomy is useful, but the broader lesson is more interesting. This is what happens when policy is applied before canonicalization is complete. In other words, OpenClaw had a safety system that knew how to make a permission decision, but not quite how to decide what object the permission should bind to. That sounds pedantic until you remember that path normalization is the whole game in command safety. If the approval is attached to the wrapper instead of the thing that actually runs, your “safe” execution model is mostly vibes.

That is why this advisory should resonate beyond OpenClaw. The entire agent-tools market is converging on the same pattern: give the model a shell, wrap it with policy, add human approvals, then claim you have made autonomous execution manageable. Maybe. But only if you resolve wrappers, symlinks, launchers, helper binaries, and dispatch shims before the policy engine decides anything. Security controls that operate on a partial view of the command path are not controls. They are ceremony.

The dangerous bugs are often the least cinematic

No one is going to make a conference keynote out of /usr/bin/time. That is precisely why bugs like this survive. They look too mundane to be scary. But safety failures in execution systems are usually boring like this. A wrapper was not unwrapped. A symlink was not resolved. A shell built the final argv differently than the policy layer expected. A helper command inherited state from the wrong context. This is how allowlists die in production, not with a dramatic exploit demo but with a thousand tiny mismatches between what operators think was approved and what actually ran.

OpenClaw’s issue also lands in a sensitive moment for the broader project. The platform has been making execution policy more visible and configurable, including shipping a first-class openclaw exec-policy CLI in the 2026.4.10 release cycle. That is good product work. Operators need to see and shape approval posture. But there is a quiet irony here too. The more user-friendly and policy-driven your execution layer becomes, the less tolerance there is for canonicalization mistakes underneath it. Better knobs do not matter if the binding target is wrong.

There is also a useful architectural signal in the fix itself. OpenClaw did not paper over the issue with documentation telling users not to call /usr/bin/time. It changed the resolution layer so the policy binds to the real executable, then added regression tests for that wrapper-specific bypass. That is the right pattern for command-execution security. Fix the model, not the symptom. If you find yourself listing every wrapper users should avoid, you already lost.

What builders should take from this

First, if you are running OpenClaw as a tool-execution surface, patch immediately and confirm the installed version includes the fix. The advisory says the vulnerable state was in 2026.3.22, while the patched behavior is present in the subsequent released tags. That upgrade is the easy part.

The harder and more valuable step is to audit your own execution pipeline for incomplete normalization. Look for wrappers like time, env, helper launchers, container entrypoints, shell scripts that dispatch onward, and any internal shim that transforms the final executable after approval has been granted. If the approval system cannot explain exactly which binary it ended up authorizing, it is not ready for production-facing autonomy.

Second, test the negative cases with intent. Most teams test that approved commands work. Fewer test that slightly disguised versions of those commands fail. The OpenClaw regression test is the right instinct because it codifies the bypass attempt, not just the happy path. Agent platforms need more of that thinking. Try wrapper indirection, argument smuggling, shell indirection, path aliasing, and transport-layer substitutions. The attack surface is not only the dangerous tool. It is the path the tool takes to look acceptable.

Third, stop treating allowlists as a silver bullet. An allowlist is only as good as the resolver underneath it. If your platform approves names while the runtime executes fully resolved binaries, the gap between those two representations is where abuse lives. The same rule applies to model tools, browser actions, MCP bridges, and plugin runners. Canonicalize first, apply policy second, log the final resolved target third.

My read is that OpenClaw is getting a useful kind of scar tissue here. The advisory is narrow, but the lesson is broad. Safe agentic coding is not only about whether an agent asked nicely before running a command. It is about whether the platform can prove that the approved thing and the executed thing are the same object. If not, the rest of the safety story is decoration. The most important execution bugs are usually normalization bugs, because that is where systems quietly stop enforcing the promises their UI makes.

Sources: GitHub advisory GHSA-qm9x-v7cx-7rq4, VulnCheck, RedPacket Security