Guide

Is it safe to let Claude Code run unattended?

Claude Code, Codex, and every other agentic coding tool can run shell commands, edit or delete files, and install packages without a human watching each step. Here is what can actually go wrong, and what meaningfully reduces the risk.

What "unattended" really means

Modern coding agents do not just suggest code, they execute it. A single prompt can end up running npm install, calling git push --force, editing config files, or piping a shell script straight into bash. Most of the time that is exactly what you want. The risk shows up in the cases you did not anticipate: a typo in a generated command, a dependency the agent misread, or a destructive flag it added because it seemed reasonable in context.

The real failure modes

• Destructive commands. rm -rf on the wrong path, a force-push that overwrites teammates' commits, a database migration run against production instead of a local instance.
• Leaking secrets. An agent reading a `.env` file and echoing its contents into a log, a commit message, or a third-party API call.
• Prompt injection. If an agent reads untrusted content, a webpage, a fetched file, an issue comment, that content can contain hidden instructions aimed at the agent rather than at you. The agent has no reliable way to tell "the user asked for this" apart from "a file the agent read asked for this."
• Autopilot approval. This is the one that is easy to underestimate. Most IDEs show an allow/deny popup on the same screen you are already working in. After the tenth prompt in an hour, clicking "Allow" stops being a decision and starts being a reflex.

What already helps

Claude Code and Codex both ship real safeguards: permission modes, deny rules for known-dangerous commands, sandboxed execution, and a hook system (see Claude Code hooks explained) that can intercept a tool call before it runs. Anthropic's own Claude Code security documentation is worth reading directly, it covers sandboxing, managed settings, and enterprise controls in more depth than any single blog post can.

The gap those safeguards do not close

Every one of those controls still resolves on the same device, and often the same screen, you are already using. That is fine when you are actively watching. It stops being fine the moment you step away from your desk, or the moment you are deep in three other windows and the approval popup becomes background noise.

Practical rules that hold up in real use

1. Read the actual command, not just the tool name, before approving.
2. Prefer "always allow" scoped to one project over "always allow" everywhere, a broad grant made for convenience today is the one you forget about later.
3. Use deny-with-reason instead of a bare deny when something looks wrong, it gives the agent the context to actually fix its next attempt.
4. Keep a deterministic policy layer (hooks, deny rules) in front of the model's own judgment. The model is good at writing code, it is not a substitute for a rule that always fires the same way.
5. If you regularly step away mid-session, route approvals to a second device rather than leaving the agent to sit idle, or worse, running in a fully unattended auto-approve mode out of impatience.

Where ÆthelHook fits

ÆthelHook is a free, open source gateway that routes every Claude Code and Codex tool call, plan review, and clarifying question to your phone for a decision, over an end-to-end encrypted connection, with no cloud relay in the middle. It does not replace the safeguards above, it adds the one thing they cannot: a decision made away from the screen you were already on autopilot with.

See how it works and download it.