Voitta AI just released voitta-yolt, and it’s aimed at a very real problem: how do you let an agent move fast in the shell without giving it a blank check?
YOLO — You Only Live Once — is the vibe-coder’s operating principle: ship now, deal with consequences later.
YOLT — You Only Live Twice — is the correction.
No, it’s not a replacement for the auto mode; it’s a more fine-grained discerment: it gives Claude Code a second look before a Bash command (or the commands it invokes, which include actual code — e.g., Python, SQL) actually runs.
The problem it solves
Claude Code’s built-in permission system has an awkward gap.
Some commands are obviously safe, but still annoying to approve over and over. Others are wrapped in ways that make broad allowlisting dangerous.
Two cases matter most:
- Arbitrary-execution wrappers.
python3,bash,node,gh api,curl,kubectl, and friends are too powerful to wildcard-allow safely. - Compound shell commands. Loops, subshells, command substitutions, and
bash -c '...'forms hide the actual inner commands from the simple outer matcher.
That means you either:
1. approve too much and weaken the safety model, or 2. approve everything manually and hate your life.
YOLT exists to get out of that false choice.
What YOLT actually does
YOLT installs as a Claude Code PreToolUse hook on the Bash tool.
When Claude is about to run a shell command, YOLT parses the invocation, walks the structure of the command, and classifies what it finds:
- safe → auto-allow
- unsafe → ask for review, with a reason
- unknown → fall back to Claude Code’s default prompt
The interesting part is that it no longer treats the shell as a flat string.
The current release parses Bash with tree-sitter-bash, reconstructs argv from the AST, and then classifies each command node against rules in rules/shell.json. If the shell invocation contains inline Python, it delegates that body to a Python AST analyzer.
And it now covers a genuinely useful extra case: common SQL CLIs. sqlite3, psql, mysql, mariadb, and duckdb get their query text inspected so read-only commands like SELECT, SHOW, and .tables can pass quietly while mutating statements like INSERT, DELETE, DROP, .import, or .load get surfaced for review.
So this is not just “grep for scary words.” It’s structured analysis.
Why that matters
This is the real improvement over naive allowlists.
A normal matcher sees the wrapper:
bash -c "..."for ...; do ...; done$(...)<(...)
YOLT walks inside those forms.
That means a loop full of read-only AWS inspection commands can be auto-approved, while a destructive operation buried inside a process substitution still gets surfaced for review.
That’s the right shape of safety tooling for agentic coding: less theater, more actual inspection.
The architectural shift
The sharpest detail in the release is that YOLT has already outgrown its first framing.
What began as a Python-script safety hook is now a more general shell-execution analyzer with language-specific followers.
The current structure is roughly:
hooks/grammar_classifier.py— Bash AST walkerhooks/rule_classifier.py— argv-level command classificationhooks/yolt_analyzer.py— Python AST analysis when Python appears inline
That’s a better architecture than a pile of string heuristics, and the repo history shows exactly why the rewrite happened: quote-state edge cases, heredocs, substitutions, continuations, and shell grammar weirdness are not bugs you “finish.” They are why parsers exist.
Using a real grammar here is the grown-up move.
Practical wins
A few details make this more than a neat demo:
- It supports both plugin install and manual hook install.
- It explicitly warns that broad static allow rules like
Bash(python3:)orBash(aws:)can bypass the hook entirely. - It can use the user’s existing
permissions.allowpatterns as a secondary upgrade pass for otherwise-unknown inner commands. - The new SQL CLI handling is exactly the sort of practical expansion I like: not theoretical safety, but fewer prompts for read-only database inspection without waving through destructive schema/data changes.
- It now defaults logging to
~/.claude/yolt.log, which makes dogfooding and debugging much easier.
And most importantly, the dogfood loop appears real. One recent pass through transcript history reportedly cut the classifier’s unknown rate from 60.2% to 11.7% by fixing a handful of recurring gaps. That’s the number I care about most, because it shows the project is being tuned against actual usage rather than imagined usage.
Why I think this matters
The broader point is not “Claude Code needs more hooks.”
It’s that agent safety gets much better when you stop treating the shell as an indivisible permission blob.
What you really want is a front-line gate for command execution: let the obviously safe paths go through quietly, and save human interruption for the suspicious stuff. That won’t replace every approval surface in an agent stack, but it can take a huge bite out of routine approval fatigue.
There is a big difference between:
aws ec2 describe-instancesaws ec2 terminate-instances ...for svc in $(aws ecs list-services ...); do aws ecs describe-services ...; donebash -c 'curl ... | sh'
A permission system that collapses all of those into “it’s Bash” is too coarse to be pleasant and too coarse to be trustworthy.
YOLT narrows that gap.
And the cleaner operational pattern is to pair that with direct API usage wherever possible. If a service already gives you a token to create a draft, update a post, or mutate a record, that is usually a better path than driving a browser through the same workflow just to satisfy the UI.
The real thesis
What’s new here is not just another safety wrapper.
What’s new is the move from tool-level permissions to structure-aware command understanding.
That is where a lot of agent tooling is headed, because the old model breaks down as soon as agents start composing commands instead of issuing one-liners.
If you want agents to operate with less friction without quietly turning root access into a vibes-based exercise, this is the kind of infrastructure you need.
Try it
YOLT is open source under AGPL v3 and available here:
https://github.com/voitta-ai/voitta-yolt
Plugin install is straightforward:
/plugin marketplace add voitta-ai/voitta-yolt
/plugin install yolt@voitta-yolt
And if you already installed it manually, the repo documents how to migrate cleanly to the plugin model.
That part matters too. Safety tooling people won’t keep updated is safety tooling that quietly dies.
Related: earlier we wrote about llm-tldr vs voitta-rag. YOLT sits in a different layer of the stack, but it comes out of the same practical question: if you are going to work with agents seriously, where do you put the guardrails so they help instead of getting in the way?

















