All posts
Sep 12, 2026·2 min read

My own robot locked me out of my computer for three hours

#ai-agents#automation#linux#safety-checks#testing

I sat down at my desktop and the screen was black. No password box, no cursor, no error. The computer was on and just wouldn't let me in, and it had been that way for three hours and seventeen minutes.

Nothing had crashed and nothing was logged. The thing that did it was mine.

Why the screen was black

On my Linux desktop, the program that draws the top bar also draws the lock screen. It watches a folder of add-ons and reloads all of them whenever a file in that folder changes.

Reloading while the screen is locked is the problem. The reload makes it forget it already owns the lock, so it tries to take the lock from itself, gets stuck halfway, and stops. The screen stays covered on purpose, since a failed lock screen should never show your desktop. You end up with a lock and nothing drawing the password box.

That day's trigger was an AI agent I had working on one of those add-ons over the network. It saved one file while the desktop sat idle-locked at home, and two seconds later I was locked out with nobody in the room to notice.

The rule that didn't work

I have a few computers and a helper that pushes updates to all of them at once. The obvious rule after that day: before writing to a machine, ask whether it's locked, and skip it if it is.

Two days later the helper reached into the same desktop from my laptop, installed an add-on, and locked me out again. Two hours and eleven minutes that time. The check had run and reported the machine was fine.

The command I was using to ask "are you locked?" works fine when you run it at the computer. Run it over the network and it can't find the desktop session, so it answers "I can't tell." And by that command's own rules, "I can't tell" means unlocked.

My guard only skipped a machine when the answer was "locked," so it let everything through: locked, unlocked, asleep. It had been in the helper since the day I wrote it and had never stopped a single write. I didn't notice, because a run where it waved a machine through looked exactly like a run where it had actually checked.

The replacement

The new check is built around how the old one failed. It sets up the session environment before asking, so the question actually reaches the desktop. It asks the lock screen program directly as well as the system, because the stuck half-lock is invisible to the system and only the program knows about it. And anything other than a clear "unlocked" or "nobody's logged in" blocks the write, since a machine that won't answer is exactly the one nobody's sitting at.

Then I made it fail on purpose. I swapped in a fake checker that always says "locked" and confirmed the helper skipped the machine. That was the first time I had ever watched the guard do its job.

If you have a safety check in your own scripts, ask three things about it. Have you ever seen it say no? What does it do when it can't get an answer? And does it mean the same thing when a script runs it from another machine as it does at the keyboard? Mine failed all three.