I run all of my Claude sessions on bypass. Every one. No confirmations, no are-you-sure, no little modal standing between the model and the machine. People hear that and their shoulders go up around their ears, and I understand the reflex.
Here is what changed. I stopped thinking of the prompt as a wall and started hearing it for what it actually is, which is a doorbell with no door behind it. It rings on everything. It rings the same way for a directory listing and for a command that reaches off the machine and does not come back. It rings so often that the ringing becomes weather, and you learn to click through weather. And when it is done ringing it remembers nothing, so if you ask it on Thursday what you agreed to on Tuesday it has no answer, because it was never keeping one.
So I built the door. It is more like a divider, and it swings both ways, and it is exactly as wide as I need it to be that day. Things pass through it. The passing is written down. That second half is the part nobody ships, and it is the whole reason the first half is safe to open.
Enough with the analogies. Let me show you the thing.
What Lotor is
Lotor is an MCP tool that writes a signed, local, tamper evident record of what an agent did in a session, and gates the actions I care about behind a signature I have to physically make.
One primitive, applied in two directions. Backward: a receipt of what happened, ordered and hash chained, so that alteration after the fact is detectable. Forward: a gate that fails closed on a chosen action until I approve it at a real terminal with a passphrase the model has never seen and cannot derive.
It runs on my machine. There is no account, no server component, no upload path. Nothing leaves because nothing was built to send it. That is not a privacy setting I toggled. There is no code in the project that could do it.
The record of what my machines did for me lives with me, and it answers to my key rather than to somebody’s retention policy.
Why bypass is the safer choice
The harness prompt and the signed gate look like the same control. They are not the same species.
The prompt fires per call, hundreds of times a session. The gate fires on the handful of things that can actually hurt me. The prompt is answered by clicking. The gate is answered by a passphrase, typed into a terminal, that reconstructs a private key existing nowhere on disk. The prompt approves a category. The gate approves one exact command string, once, and will not stretch to cover a second one that merely resembles it.
And then the difference that matters most. The prompt forgets. The gate records the denial and the approval both.
That is the line I would underline if I could keep only one. A control that only says no is a nuisance. A control that says no, and then writes down that it said no, and writes down what changed your mind, is bookkeeping. It is the difference between a bouncer and a ledger.
So yes, I turned off the thing that was asking. I did it because I finally had something that was answering.
The night it turned out to be off
I should tell you how this got serious, because the honest version is better than the version where I planned it.
I shipped a site deploy through a tunnel to a Raspberry Pi. One point three megabytes left this machine. My gate, which I had been describing to people in the present tense for weeks, produced nothing. No match, no warning, no request for a signature.
Three failures stacked, each one sufficient on its own. Every command rule was keyed on the tool being named Bash, and the deploy went out through PowerShell, so the primary shell on my own machine was invisible to all of them. The mode was set to warn, so even a match would only have muttered. And underneath both of those, the real one: the enforcement hook existed in the repository, two hundred and fifty lines of fail closed logic, complete and correct, and it was wired to nothing.
I believed the gate was live because I had set up the signing key. Key present is not gate armed. Nobody had checked the second thing, and the second thing was the whole thing.
My first instinct was to write it up as a known limitation and move on. That instinct was wrong, and I want to name it because it is the failure mode of anyone who has been practising disclosure for a while: a gap in enforcement is not a documentation problem. Content leaving through a tunnel unsigned is not a limits entry. It is the absence of the protocol.
So I armed it, and then I spent a day working against it on purpose.
Five holes, found by using it
Arming the gate and then trying to do real work through it found five defects in a day. Every one came from operating the thing. An audit of the rule list would have found none of them, because on paper the rules covered what they claimed to cover.
The rule protecting the gate’s own source could not tell reading from writing, so inspecting it cost the same as changing it. It blocked a command that merely named a protected file, which meant writing documentation about the gate looked identical to modifying it. It allowed a full clone of the entire repository, gate included, to an unwatched location, while blocking a one line read of the same file.
A delegation feature I designed over three sessions turned out to cover a set that was empty. Four commands of measurement killed it, and the redesign is what shipped. And the authorisation record was being written to a file and never to the chain, so the log could say that something had been approved and could not say what. I found that one while tidying up, by deleting a stale record and noticing nothing was left behind.
There is a particular flavour of finding that only shows up under load. My favourite: a worker process reported which model it was running on, in the section of its own report reserved for admitting uncertainty, and it was wrong. The receipt was right. A model was mistaken about its own identity and the host observed record corrected it.
That is the entire argument for keeping the record outside the thing being recorded, and I did not have to construct it. It happened while I was doing something else.
What I actually use it for
I am going to separate these by evidence, because a list where everything sounds equally real is a list nobody can act on.
Proven, in daily use. Gated high stakes actions: deploy, push, delete, spend, all failing closed, with the signature bound to the exact command rather than to a category. Long horizon coding, where a gate that costs a trip to a terminal per action is a gate that gets switched off during exactly the sessions worth gating, so one signature now covers an enumerated set of requests bound to one session, with an expiry and a use ceiling counted off the chain. Asking what actually ran, cheaply, because reconstructing history burns tokens through rereading and rederiving and holding it all in the window, while querying a receipt costs almost nothing and does not depend on the agent’s account of itself. And a signed receipt per session: what ran, what it touched, what it sent, what it cost, what failed, with failures surfaced rather than buried.
Built, lightly exercised. Three named modes instead of a nine switch matrix. A morning after view of an unattended run. Detection of sessions that ended badly, which are the ones most worth having a record of.
Not built, and named here so no sentence above carries a promise it cannot keep. Scoped sharing of a redacted slice with an outside party. External anchoring, without which the chain proves alteration and stays silent on erasure. Hardware backed key custody. Per model cost attribution.
What it is not
I would rather you find these here than find them yourself and conclude I was hiding them.
It is not a sandbox. It does not contain anything. It stops chosen actions and records the rest. It is not built to survive an adversary engineering around the matcher; the threat model is an honest agent going off script inside normal tool calls, not a model actively working to defeat a pattern. Capture is self attested, which means a clean receipt and a missed event look identical, and no amount of tamper evidence closes that gap. It detects, it does not predict. It tells you the floor is gone. It does not put one back.
All of this lives in a file in the repository called KNOWN-LIMITS, which currently runs to twenty one entries. It is the first thing I would read if somebody handed me this project, and it is the artifact I am most willing to be judged on. Anyone can write a feature list. A file documenting your own product’s weaknesses, against your own interest, is the only claim in the whole repository that is expensive to fake.
The company cannot audit itself. Neither can I. So I wrote down where I am weak and left it where you can find it.
Where the floor is
The bassline under all of this is older than the tool. A record kept by the party with something to lose is not a record. It is a press release with timestamps. The only version that survives contact with a real dispute is one the interested party never held.
So the receipt is written here, to this machine, under a key derived from something in my head. If the vendor changes, it stays. If the model changes, it stays. If I am wrong about something, and this week suggests I will be, the record of being wrong stays too, and that is the part I would defend hardest.
I am not going to tell you this made anything safe. It closed five holes and opened a file listing the ones still open. What it did is smaller and more useful than safe: it made the floor checkable. You can stand on a floor you can check. You cannot stand on a promise, however sincerely it was made, and most of what is being sold right now is a promise wearing a floor’s clothing.
Show up. Find the floor. Hold the tempo while the rest of the band works out where the song is going.