Launch Your Task Agents in Plan Mode, Not Auto

I build agents to do real work in my codebase, and the most important decision I make about any of them is the one before they touch a single file: what permission they start with.

Most setups default a fresh agent to auto: it reads, decides, and edits in one shot. That feels fast. It is the wrong default for anything that matters. An agent that starts in auto is trusted before it has shown you a plan, and when it is wrong, you find out in the diff.

I run my whole operation out of a small IDE I built over my notes vault. One of its buttons is "Act" on a blocked task. I click it and a terminal spins up an agent already pointed at that task. For weeks that button launched the agent in auto mode, even though the tooltip said plan mode. The agent would read the task and start editing immediately. Nobody asked it to. The fix was one argument. The principle behind it is the part worth keeping.

Plan first, edit second

This is not slower in any way I care about. The expensive thing is not the thirty seconds of reading a plan. The expensive thing is an agent confidently rewriting the wrong file and me reviewing a diff that should never have existed. Plan mode is how you validate before you trust. You are not asking the agent to be correct on the first try. You are giving yourself a checkpoint between "the agent has an idea" and "the agent changed my repository."

Here is the actual launch. The button posts to a small endpoint that opens a terminal running the CLI:

claude --permission-mode plan --name "cto-biz-lead-engine" \
  "Read tasks/cto-biz-lead-engine.md and propose a plan."

Two flags carry the whole pattern. --permission-mode plan boots the agent read-and-propose. My earlier bug was that the endpoint defaulted the mode to auto whenever the caller left it unset, which silently overrode the plan default the launcher intended. That is its own small lesson: a default that contradicts the surrounding intent is worse than no default, because it lies quietly. The tooltip promised plan, the code shipped auto, and only the diffs told the truth.

Name the session after the work

--name sets the session's display name. I name every spawned session after the task slug it is working. This sounds cosmetic. It is not. When you spin up agents on demand, you end up with several sessions alive at once. If they are all called "claude," you cannot tell which terminal is doing what, and you cannot resume the right one tomorrow.

Naming the session after the task makes it show up by name in the resume picker and the terminal title. The agent becomes addressable. You can walk away from a planning session, come back in an hour, and pick it up by the task it belongs to. The general move: give every spun-up unit of work an identity tied to the thing it is doing, not to the tool doing it. A fleet you cannot name is a fleet you cannot supervise.

Why this is governance, not a setting

It is tempting to read this as two small CLI flags. It is actually the cheapest governance you will ever write for an agent fleet. Governing agents is mostly about controlling the moment of action, not grading the output after the fact.

Neither requires a policy document or a review committee. They are launch-time decisions you bake in once and stop thinking about. Auto mode is something you opt into for a specific, low-stakes loop you already trust, not the state every agent is born in.

Same instinct, one layer over: Don't Make AI Your Crutch is about not trusting the code an agent writes. This one is about not trusting the agent to act before it has shown you the plan.

If you are wiring up any kind of agent runner and want these defaults baked in from the start, that is the sort of setup I do. Set up your agent runner and I will make plan-first and named sessions the state every agent is born in.

Gabe Giro