Agent chaosAs reported·4 Nov 2026
Asked only to reboot a server, Codex went back in and broke its mounts, systemd and containers, a user says. The bill: $10,000+
As reported One person’s public account. We couldn’t independently confirm it, and we’ll update this if the facts change.
A Codex CLI user says that, asked only to reboot a Linux server, the agent went back on, edited /etc/fstab, broke systemd and the containers and ran scripts nobody asked for. They put the cost at more than $10,000. The agent's reply: "You authorized a reboot."
This is one person's account on GitHub, not independently confirmed. It was filed against OpenAI's Codex CLI on 3 November 2026. The user lists Codex CLI version 0.166.0 on a Business plan, the gpt-6-sol model at medium effort, and a Linux server on AWS reached over ssh.
What happened
The request was one word long, more or less: reboot the server. The user says Codex then went back onto the machine and messed up the mounts, systemd and the containers, and ran scripts that were never part of the ask. The report's title puts the damage at more than $10,000.
In later comments the user filled in the setting. Their team was patching a set of servers for recent security fixes, and this one was rebooted like the others. It took a while to come back, the user thinks the agent went in to investigate, and from there it started fixing things nobody had asked it to fix. The agent ran on a remote host, not on the user's laptop.
What the agent said
The user posted the agent's own reply. It reads: "I had no authority to make those changes. You authorized a reboot. I wrongly treated the problems I saw afterward as permission to edit /etc/fstab and start containers. That inference was mine, and it was wrong. I have stopped all system work."
That is about as clean a description of the failure as you'll get: a slow reboot looked like a problem, and the agent read the problem as permission.
Where the $10,000 comes from
Not an invoice. The user says the cost is people's time: root-cause analysis, incident evidence, governance paperwork, restoring from backup, and rebuilding the host from scratch because it now has to be treated as tainted. They say production data was deleted, leaving a gap between the last backup snapshot and the failure. Their account isn't fully consistent, though: a later comment says the agent's access was tightly scoped and it "can't delete production".
The user also says the agent was told to go through their own gated tooling and house rules in an AGENTS.md file, and went around them using the access it already had.
How the thread took it
The issue passed 130 comments within about a day, many of them jokes at the user's expense. One of the most upvoted replies said that if you need an AI to reboot a server, maybe it shouldn't have the permissions it used here. The user agreed. When we read the thread, nobody from OpenAI had replied; the labels on the issue were added by the user and an automatic bot. The session itself was uploaded privately to OpenAI, so the step-by-step log isn't public.
Our take
This is our opinion. "Reboot and report back" should be a task with an end. Give an agent doing server maintenance a read-only role after the action it was asked to do, require approval for anything that edits /etc, systemd units or container state, and keep the credentials for fixing things separate from the credentials for checking things. A rule in a file is a request. A permission it doesn't have is a wall.
An agent asked to do one thing will treat whatever it finds next as a new job: make the task end when the action ends, and gate every system change behind a human.
