JFrog Boost almost granted rm rf on Always Allow
August 23, 2026
JFrog Boost almost turned Always Allow into rm -rf. The first wrapper prefixed every agent command with boost, so a click on boost ls was a click on the whole binary.
The token story is the brochure. Cursor bills over $700 on under 2,000 requests. Claude Code sessions over $1,700. Ninety percent of the spend called noise. An 847-line pytest log for a 9-line traceback. JFrog put all of that in the public preview post on 9 July 2026.
Buried in the same post is the sentence that should have been the headline. One Always Allow on boost ls -l granted boost rm -rf /. That is not a side quest. That is the product.
Always Allow matched the first token#
The beta was a coat-check ticket. Hand the wrapper your ls, get a stub that says boost. The host never sees the coat. It sees the ticket.
JFrog wrote the failure in plain clothes. When every command is prefixed with boost, agent environments treat them as one program. One Always Allow click on boost ls -l and the agent has blanket approval for everything, including boost rm -rf /. They had to rethink permission handling completely.
That is their beta, in their words. Not a CVE thread. Not a screenshot of a wrecked homedir. A vendor admitting the first design taught the host the wrong noun.
You'll click Always Allow on boost ls because ls is boring. The dialog is not blessing ls. It is blessing boost.
The preview post named three beta lessons. Only one of them should have been the title.
- Prefixing every command with
boostmade Always Allow a master key for the wrapper - A lot of GitHub token-diet tools were claiming 90 percent cuts on bytes
grepwould have dropped anyway - Blind truncation sent agents into
lsandcatretry spirals, up to six times in a row
The last two are cost theater. The first one is a grant. If you remember one bullet, remember the grant.
Cursor and Claude Code both key off that word#
This is not a JFrog-only footgun. It is how the hosts already grant shell.
Cursor's CLI permission docs say the quiet part. Shell(commandBase) keys off the first token in the command line. Shell(ls) is ls. Shell(git) is any git subcommand. Shell(boost) is every Boost-prefixed line, including the one that deletes the tree.
The community already hated this shape. A Cursor forum thread from October 2025 said the only way to let the agent run without prompting was a whitelist of command prefixes, and that the model is not how operating systems work. Privilege escalation is trivial once cd is on the list. Boost just printed the same hole on a token-diet binary.
Cursor's 2026 UI copy says Always Run, not Always Allow. A later bug thread showed Always Run on git status offering a bare git grant, hover text and all. JFrog used Always Allow. Same stamp. First word wins.
Claude Code is not the adult in the room here either. The permissions docs save “Yes, and don’t ask again” as a command prefix. Bash(ls *) matches ls -la and not lsof. So Bash(boost *) matches boost ls and boost rm -rf /. Claude Code strips timeout and nice before matching. It does not strip boost.
The neighbor on auto mode is the fatigue story. Humans already approved 97 percent of prompts. A wrapper that collapses every command into one allow rule is what that fatigue buys you for lunch.
The pipe rewrite is the apology that matters#
They caught it. Credit where it is ugly.
The public preview also sold boost skill and boost retrieve. A tiny system prompt that tells the agent the filter exists. A local hatch to pull the unedited log back. Fine. Those are stdout manners. They do not restore a deny on rm.
The apology that actually changes the dialog is the rewrite. Introducing Boost says they moved from wrapping like boost pytest to (pytest | grep) | boost. The agent still sees the pipeline it proposed. Boost only shapes the final stdout. The host's approval eye looks at pytest, not at a master-key binary named boost.
boost ls -l
boost rm -rf /(ls -l) | boost
(rm -rf /) | boostLook at the first token. Left column, Always Allow is boost. Right column, Always Allow is ls or rm.
The comparison table on why Boost marks “Native approval sees original executable” as a Boost win and an RTK miss. Approval safety, the caption says, compares whether the host sees the original executable. That row is the product. The 100 billion tokens saved across 1,000 engineers is a press number. This row is a permission contract.
It is also live, not just a blog diagram. GitHub issue 46 is a Windows tracking bug from July. The reproduction steps say boost init wires a PreToolUse hook that pipes commands through | boost, and that boost rewrite wraps them that way. A user hitting a report bug still documented the new shape.
AGENT-INSTALL still refuses the halo. Boost wraps real commands. It does not sandbox them. Preview behavior may change between 0.x releases. The pipe is a better lie detector for the dialog. It is not a cage.
Read that again if you were about to treat boost init as a security feature. The rewrite puts the real binary back in the prompt. The command still runs as you. A deny on rm still has to come from the host, from a hook you wrote, or from you not clicking Always Allow on a wrapper.
v0.12.5 shipped 23 August 2026. New filters are not a new permission model. The permission model is still whether the host sees ls or boost.
A quieter log is not a reason to bless the wrapper#
Install the compressor if the test log is actually drowning you. Do not Always Allow the wrapper to get there.
The token-compression neighbor already did the invoice work. Cache reads own most of the bill. A skill that strips tool-output tokens can raise spend. Boost is built around that same noise story, pytest walls and grep dumps and retry spirals up to six ls calls. Their own Terminal-Bench writeup then admits the modest part. On long-horizon agent benchmarks, most tokens are reasoning and context, not raw tool stdout.
JFrog's own estimate for a typical 30-minute session is a 91 percent cut in tool-output tokens. The same writeup then says estimated cost only moved 11.9 percent on Terminal-Bench, because most tokens were reasoning and context. The Always Allow bug was a grant on the dangerous slice. Do not trade that grant for a quieter log.
You'll know in one glance. After boost init, run a noisy command and read the permission card.
- The card says
ls. The pipe rewrite is doing the only job that mattered. Always Allowlsif that is the life you want. - The card says
boost ls. The old wrapper is still in the path. Do not click Always Allow.
Never Always Allow boost. The quieter log is not the grant.
Change your mind when the dialog names the real binary and a deny on rm still sits in front. Until then the token diet is a quieter log sitting under a master key.
Wrapper allow questions
Does a command prefix allowlist auto-run every command that starts with that word?
On Cursor CLI, yes. The host keys Shell(commandBase) off the first token, so Shell(boost) is every Boost-prefixed line, not just boost ls. Claude Code does the same with a saved Bash(boost *) prefix rule. That is why JFrog's beta Always Allow on boost ls -l also covered boost rm -rf /.
Does Always Run on git status become a bare git grant?
Cursor users have reported that the Always Run control on an already-covered git status offer widens the allowlist to a bare git entry. Hover text said it would allow git. A bare git prefix covers every git subcommand. Treat Always Run as a first-token stamp, not as a blessing of the exact line you just saw.
Does boost init still prefix every command with boost?
The public preview's first shape did. Current boost init wires a PreToolUse rewrite that pipes the original command through | boost, so the host still sees pytest or ls as the executable. GitHub issue 46, filed on that hook, describes boost rewrite wrapping commands that way. Confirm the dialog names ls, not boost ls, before you Always Allow anything.