A seatbelt for AI agents
TL;DR: Little Control Room now blocks most direct rm -rf commands before an AI agent can run them. It is a deliberately narrow guardrail, not a security sandbox. We think real-time checks by small, local LLMs will become an important safety and privacy layer, catching risky actions that don't look like rm without sending sensitive context elsewhere.
AI coding agents can now do a surprising amount of useful work on their own. Little Control Room lets us start work across several projects, give agents the tools they need, and supervise the results without turning every step into a permission ceremony.
That also gives agents real access to our computers. A sandbox that hides other repositories, shared assets or our own tools quickly makes them less useful. Broad access is valuable, but it turns a small reasoning mistake into a potentially large practical problem.
An AI doesn't need to be malicious to destroy data. It only needs to misunderstand a path once.
The rm -rf problem
The classical Unix foot-gun is:
rm -rf "$TARGET"
There is nothing wrong with this command when $TARGET points to a disposable directory. The problem is that a shell doesn't consider intent. It expands the variable and does exactly what it was told to do, possibly with much more enthusiasm than the person or model issuing the command expected.
Little Control Room now adds a narrow seatbelt around this. In embedded Codex sessions, a direct rm command is blocked, with one deliberately constrained exception: recursive forced deletion is allowed for a validated descendant of /tmp. Absolute forms such as /bin/rm and common wrappers that could bypass the guarded command are blocked as well. LCAgent is stricter and rejects direct rm commands completely, regardless of its permission level.
The implementation isn't a raw regular expression looking for the letters rm. LCAgent parses the Bash or Zsh command structure, so writing about rm -rf / is not confused with executing it, while command chains, shell substitutions and common wrappers can still be recognized. The Codex side combines native command rules with a guarded executable in its controlled environment.
This protects against a common accidental command. It isn't a security sandbox, and it doesn't make deletion impossible. The full policy and known bypasses are linked below.
A quick heuristic
The current policy is a heuristic: it identifies one particularly dangerous class of action and stops it at a convenient chokepoint. This catches the obvious case, including the one most likely to appear when an agent decides to "clean up" a directory.
But files can also be deleted through find -delete, Python's shutil.rmtree, direct filesystem APIs and many other mechanisms. Destructive work doesn't even have to involve deletion. Overwriting a configuration, discarding Git history, truncating a database or removing a cloud resource can produce the same outcome without looking anything like rm -rf.
We can keep adding rules, but that quickly becomes an endless collection of dangerous-looking strings. The same command can be harmless in one context and catastrophic in another. Removing a generated build directory is normal. Removing the only copy of an unfinished project is not. The text of the command alone can't tell the difference.
Still, a heuristic that prevents a large and obvious mistake is worth having today. A seatbelt doesn't make a car crash-proof, but this isn't a good reason to drive without one while waiting for something better.
A model watching a model
We think real-time, LLM-based checking will become an important layer for both safety and privacy.
These reviewing models don't need to be particularly advanced. The task is narrow: inspect a proposed action and return a small, structured assessment. That makes it a good candidate for a smaller model running locally. Keeping the review on the machine means paths, commands and surrounding context don't have to be sent to another service. The same check could also flag an action that is about to expose credentials or private data.
The reviewer would not simply search for a command name. It could look at the user's request, the proposed action, the current directory, the affected paths, the Git state and whether the operation is reversible. A shell command, a Python script and a tool call may all express the same destructive intent even when their surface forms are completely different.
The reviewing model should not silently grant permission to another model. Its role can be limited to producing a structured risk assessment, while a deterministic control layer enforces the policy: when the assessed action crosses the destructive threshold, execution stops and the user is asked to confirm it. The model provides the semantic understanding, but the deterministic system owns the brake.
This still won't be perfect. We're using one non-deterministic system to help supervise another. But it would cover much more than command matching, and it can be combined with backups, version control, operating-system permissions and a few hard rules for actions that should never happen automatically.
The case for owning the tools
This is another example of why we believe in building and owning our tools. Little Control Room started as an internal solution for working with several coding agents across many projects. Because we own the layer through which those sessions run, we can add safety where it is needed, test it against our actual workflow, and adjust it when it becomes too restrictive. We don't have to wait for an IDE vendor or AI provider to decide that our problem is important enough.
This doesn't mean everyone needs to build an operating system or a new IDE. It means it is increasingly valuable to own the relatively thin control layer where authority passes from an AI model to our computers.
We're in a dynamic phase. Models, providers and agent frameworks change constantly, and the underlying capabilities can move faster than a polished general-purpose product can settle.
Building fast therefore also means protecting ourselves fast. We are all increasingly responsible for our own computer security, because the boundary between "what we did" and "what our agents did on our behalf" is becoming very thin. We expect agents to become more reliable, but we also expect to give them more authority. Those trends don't cancel each other out: a rare mistake across many projects can still be very expensive.
For now, the rm guard in Little Control Room is small, practical and intentionally imperfect. It stops one ugly class of accidents today, while making the limitations explicit. Broader safeguards will need to understand destructive intent rather than just destructive commands.
The faster we build, the more important it becomes to own the brake.