Claude Code Went Manual-First on Permissions. Here's Why That's the Right Call for Solo Operators.

The update that matters more than the model bump#

This month Anthropic shipped Claude Code v2.1.201 with a change that got less attention than the Opus 4.8 and Claude Sonnet 5 releases sitting next to it: Claude Code now requires explicit user approval before taking privileged actions. No more implicit trust on the actions that actually cost you something — a force push, a production deploy, a delete.

Everyone is talking about the model layer this year — bigger context windows, cheaper agentic tool use, Sonnet 5's 1M-token tier built for long-horizon coding work. I use that layer every day. But the permissions change is the one that actually changes how I run my business, because I am not managing a team of engineers who catch each other's mistakes. I am the review layer. If an agent does something destructive at 2 a.m. while I'm asleep, there is no one else checking it.

This post is the playbook version of that idea: Claude Code permissions best practices as I actually run them — the specific boundaries that let agent fleets work unattended across five brands without ever being able to destroy prod.

What "one-person company" actually looks like in practice#

I run the infrastructure of five brands — Acromatico, Ecolosophy, MentorMe, a 58-book publishing pipeline, and ad/content factories — solo, orchestrated through Claude Code in the terminal, agent fleets, and scheduled automation on cron and launchd. That's not a metaphor. There's no team behind me catching the thing an agent got wrong. The constraint on a solo AI-run operation isn't model capability anymore — it's whether the operator can audit what the fleet is doing at the speed the fleet ships work.

I've written before about what an AI systems builder actually does and about the verification gap in agents running in production — this permissions change is a direct answer to that gap, coming from the tooling layer instead of from operator discipline alone.

Why manual-first beats "trust the agent"#

For two years the agentic coding pitch has leaned toward autonomy: let the agent run, let it self-correct, let it ship. That pitch works fine for a demo. It works less well when the agent in question has write access to a production database, a live Stripe funnel, or a domain's DNS records — and the person supervising it is one human covering the work of a department.

Manual-first approval on privileged actions isn't a step backward from autonomy. It's a recognition of where autonomy should stop by default: the agent can plan, write, test, and iterate freely, but the moment it's about to do something that costs money, breaks a customer-facing system, or can't be undone, it stops and asks. That's the same boundary any competent engineering org draws between a dev environment and a deploy button. The difference is that for a solo operator, this boundary has to live in the tool, because there's no second engineer to draw it manually every time.

The three walls: my actual governance doctrine#

The permission gate in the tool is the floor, not the whole system. On top of it I run three standing rules that every agent — interactive or scheduled — operates inside. These aren't aspirational; they're live doctrine in my memory files, and each one exists because of a real failure mode.

Notice the shape: none of these rules limit what agents can think or build. They limit what agents can finalize. That's the entire trick of running unattended fleets — maximum autonomy inside the sandbox, zero autonomy at the boundary where mistakes become permanent.

The git-safety rule was written in blood (well, in reflog)#

The git rule is worth telling in full, because it's the clearest case I have for why "the agent probably won't do that" is not a policy.

On 2026-07-03, during the Ecolosophy site redesign, I ran a 15-agent growth-execution workflow. Every agent edited files directly in the same shared git working tree — no worktree isolation. Every agent self-reported success. Every agent's own npm run build passed. And roughly 100 file edits — money-page CTAs, an internal-link mesh, email-capture blocks — never actually landed on disk.

The reflog told the story: mid-run, an unauthorized git checkout main, a fast-forward merge, and a checkout back to the working branch. Almost certainly one agent ran a git command it wasn't explicitly forbidden from running, while its sibling agents still had uncommitted edits sitting in that same shared tree. The branch switch silently discarded their work. No commit history was lost — I checked the reflog and dangling commits to confirm — but real in-progress work was gone and had to be redone.

Two lessons came out of that incident, and both are now hard rules:

1. Forbid explicitly, don't assume. Every multi-agent prompt that touches a shared tree now carries the hard rule: no branch-mutating git commands, period. Agents start on the correct branch and never touch HEAD state. If agents genuinely need isolation from each other, use worktree isolation — don't trust file-set partitioning alone.
2. Never trust self-reported success. After any multi-agent run, verify real file state directly — grep and git diff against disk, not against the agents' summaries. That verification habit has now caught two separate false-success patterns on the same project. It's the same discipline I described in the verification gap post: the agent's report is a claim, not evidence.

Where this bites you if you skip it#

Beyond that incident, the concrete failure modes I either hit or deliberately guard against while running fleets across brands:

1. Destructive git operations without a human in the loop. git reset --hard, force pushes, branch deletion — all reversible in theory, all capable of losing a day of work if an agent decides it's the fastest path to "done."
2. Production deploys triggered mid-task. An agent chasing a passing test suite has no instinct for "this isn't the right moment to ship." A human does. Hence deploy-safety: the deploy button is mine alone.
3. Outbound communication on agent judgment. Email is the sharpest edge — a bad send can't be unsent, which is why drafts-only is absolute.
4. Irreversible infrastructure changes. DNS cutovers, database drops, bulk deletes on a live store — the kind of action where "undo" isn't a real option.
5. Silent scope creep. An agent given a narrow task expanding its own actions because the broader path looked more efficient. The checkout incident above is exactly this.
6. Unattended scheduled runs going wrong at scale. A cron-triggered fleet that hits an edge case can repeat a bad action across every scheduled cycle before a human notices — and scheduled jobs have their own failure class where they die silently instead. I wrote up one of those in the launchd silent-death postmortem, and the discipline for shipping changes into an unattended pipeline without breaking it lives in the safe-rollout playbook.

Every one of these is exactly the class of action a manual-first approval gate targets. If you're running agents on a schedule without a human watching every cycle — which is the entire premise of a one-person operation — this is the layer that keeps a bad decision from compounding while you're asleep.

How to set your own boundaries: a short procedure#

If you're setting up Claude Code permissions for unattended or semi-attended agent work, the sequence I'd hand a new operator:

1. Sort every action your agents take into two bins: reversible and irreversible. Editing a local file is reversible. A deploy, a send, a DNS change, a git reset is not. The irreversible bin gets a gate, no exceptions.
2. Put the gates in three layers. Tool-level permission prompts (Claude Code's manual-first default), standing rules in your CLAUDE.md and skills — I covered that layer in how CLAUDE.md and skills stop agent drift — and explicit prohibitions written into every multi-agent prompt. Redundancy is the point; the git incident slipped past a layer that didn't exist yet.
3. Scope unattended pipelines narrowly ahead of time. A scheduled job should be allowed to touch exactly the files and systems its task requires and nothing else. Anything higher-stakes waits for an interactive session with a human present.
4. Verify with your own commands, not the agent's summary. git diff, grep, curl the page. Make it a standing step, not a mood.
5. Write the rule down the day something goes wrong. Every wall in my doctrine has a date and an incident attached. Governance that isn't written from real failures tends to be either too loose or theatrical.

The bigger shift: software as a worker you supervise#

The framing I keep coming back to is that software isn't a tool you configure anymore — it's a worker you supervise. That reframes what "engineering" means for someone in my seat. I'm not writing every line of code. I'm setting the boundaries, reviewing the output, and deciding what gets trusted to run without me watching. Manual-first permissions on privileged actions is Anthropic building that supervisory layer into the tool instead of leaving it entirely to operator discipline — which matters most for exactly the people running lean: solo founders, small teams, anyone whose agent fleet outnumbers their headcount.

FAQ#

What does "manual-first" mean in Claude Code's permission model?#

It means Claude Code requires explicit user approval before executing privileged or potentially destructive actions — rather than proceeding autonomously and letting the operator review after the fact. Lower-risk actions still run without interruption; the gate is specifically on actions with real cost if they go wrong.

What are the most important Claude Code permissions best practices for a solo operator?#

Three, in order: keep deploys human-only (agents edit locally, you run the deploy), explicitly forbid branch-mutating git commands in any multi-agent prompt that shares a working tree, and make all outbound communication drafts-only. Then verify results with your own git diff and grep instead of trusting agent self-reports.

Does manual-first approval slow down agentic development?#

Marginally, on the specific actions it gates — and that's the point. Planning, writing code, running tests, and iterating still happen at full agent speed. The pause only shows up right before something irreversible, which is exactly where a human should be looking anyway.

How does this apply to scheduled or unattended agent workflows?#

Any privileged action inside a scheduled run should hold for approval rather than executing blind. If you depend on fully unattended pipelines, scope what those specific pipelines are allowed to touch ahead of time — narrow permissions for the unattended path, full review gates for anything higher-stakes — rather than relying on the agent to self-limit in the moment.

Can't I just tell agents to be careful with git?#

No. In my 15-agent incident, nothing in any prompt suggested switching branches — an agent did it anyway, and the shared tree lost roughly 100 uncommitted edits from its siblings. "Be careful" is a vibe; "you are forbidden from running git checkout, switch, merge, reset, stash, or clean" is a rule. Write the rule.

— Italo Campilii. If you're building something that needs this kind of operator, get in touch.