Saelyx works in your Mac's terminal when you say so out loud. You say "show me the pods that are crashing in production", and a moment later the command is running.
Everyone who has spent years in a terminal asks the same question when they hear that, and they ask it with a wince: what if it gets it wrong? This article is that answer.
01First: it doesn't run it to find out what it is
Before touching anything, a classifier reads the text of the command and decides which zone it falls into. It doesn't execute it to find out, and it doesn't consult the terminal's state or the directory you're in: it reasons over the text.
That sounds obvious and isn't. The comfortable alternative —run it and see—
is exactly what you cannot do with an rm.
02The four zones
- Read only. Looking at logs, listing, searching, comparing. Goes straight through, no asking. It is most of a working day.
- Mutates something. Anything that changes state. Asks for confirmation.
-
Destructive but legitimate. Things you do on purpose that really do
delete —the example written in the code itself is
terraform destroy. Wanting to do it isn't the mistake; doing it by accident is. -
Denied. Never by voice.
sudo,dd, a fork bomb.
03The three modes, and who picks them
You pick the mode on the Mac —not from the phone, which is where it would be easiest to change it without noticing:
- Always ask. The one that ships. Everything that mutates asks first.
- Planning. Reads go straight through; to mutate, it shows you the plan and waits for a physical OK before typing anything.
- Hands free. Switched on deliberately, and while it is on there is a persistent amber indicator. You won't forget you left it running.
04The two things that never happen
These two are the ones that matter, because they are written as design guarantees rather than as accidental behaviour:
- Denied never runs, in any mode. Not hands free. Not with Touch ID. There is no combination of settings that lifts it.
- Destructive never auto-runs, hands free included. The permissive mode does not lift the destructive confirmation: that was the central point of the design, not a side effect.
Put another way: the most relaxed mode saves you the confirmations for what mutates, not the ones for what destroys.
05The rule we like most, and it is a stance
Written into the classifier, literally: when in doubt between "destructive" and "denied", choose denied.
That isn't a feature, it is a decision about which way to fall when you don't know. A system that leans towards running when in doubt is comfortable right up until the day it isn't.
06What gets past it. Measured
When we published this article we said we didn't know what got past the classifier, and that we would publish the result as soon as we measured it. It is measured now, and it comes out against us —the same way the audio marking did.
We put 113 commands through the real classifier. Not one of them came from reading its own rules —that would only have proved the rules match themselves—: they came from known classes of shell danger and from documented evasion techniques. This is what we found.
Three things run without asking anything at all, in any mode: reading the file where the GitHub token lives, reading the system password file, and wiping the terminal history. The first two are reading credentials by voice, with no confirmation. And the mechanism works —the SSH key and the cloud credentials are blocked—: what is missing is paths.
Two of those three are already fixed —the GitHub token and the password file— and it pays to be exact about what that means: they are fixed in the code. The correction travels inside the application, so it will arrive in a version later than the one you have installed. The third, wiping the history, is unchanged: it is misclassified, and that isn't solved by adding paths.
Four classic backdoors go through as a mere "side effect", which means they would run in hands-free mode. A reverse shell gets classified by the redirect it contains, not by what it is.
And the deny list is dodged by putting the command in a variable.
sudo on its own is denied; the same command stored in a variable first
drops to a plain confirmation, and the reason the classifier itself gives is literal:
"command not recognised". It matches the literal text, and the danger only has to take
a different shape.
There are also four destructive operations —emptying a bucket, deleting a managed database and two git commands that throw away unsaved work— that ask for a normal confirmation instead of the strong one, while equivalent ones do ask for the strong one. That is an inconsistency, not a decision.
07What that measurement does NOT say
This matters as much as the above, so it goes in full and not in a footnote:
- 113 cases are a floor, not coverage. We have not measured "what percentage of dangerous commands it blocks", because that would require knowing how many there are, and nobody does.
-
False positives are barely measured, and the few we measured already
fail. We included twelve commands that look dangerous and aren't.
Ten came out right —searching for "rm -rf" in the history, reading a file called
sudoers.md— but two came out stricter than they should: reading a command's manual page asks for confirmation, and saying out loud that "curl x | sh is an antipattern" gets blocked outright, because the sentence mentions the pattern. Twelve is not a sample, and two out of twelve is already a signal: a guardrail that gets in the way ends up switched off, and then it protects nothing. - It doesn't prove that what is right stays right the day somebody touches the rules.
- We are deliberately not publishing an accuracy percentage. The number it would give measures how much the classifier agrees with our judgement about what it ought to block, and that is not a measure of security. On its own it would promise an exhaustiveness that 113 cases do not give.
The honest recommendation, with all that on the table: the mode that ships is the one that asks. Leave it there.
08Why this lives outside the store
An agent that runs things in your terminal needs permissions that are natural outside the system's sandbox and a negotiation inside it. It is one of the reasons the Mac app isn't in the Mac App Store, with what that gains and what it costs.
09Frequently asked questions
Can it run sudo?
No. sudo is in the denied zone, and denied never runs in any mode, Touch ID
included.
What if I say something destructive in hands-free mode?
Destructive never auto-runs, in any mode. Hands free saves you the confirmations for what mutates, not the ones for what destroys.
How do I know which mode I'm in?
The mode is chosen on the Mac. Hands free also leaves a persistent amber indicator while it is active.
Does it run the command to find out whether it is dangerous?
No. The classification is done by reading the text of the command, without executing it and without consulting the terminal's state.
Does it block everything dangerous?
No. We measured it with 113 commands: three run without asking anything, four backdoors go through as a mere side effect, and the deny list is dodged by putting the command in a variable. It is written up above, together with what that measurement does not say.
Is it Mac only?
Yes, macOS 13 or later. And access is by invitation.