Before the agent touches the repo, show me the plan

I’m increasingly uneasy with coding agents that can edit a repository, run shell commands, install packages, and reach the network while presenting autonomy as a convenience feature. Constantly approving every command is unusable, but opaque autonomy turns the repo, package manager, shell, and network into one large attack surface.

I’d prefer a human-readable execution plan before risky actions: expected file changes, commands, package installs, and outbound destinations, grouped into a reviewable checkpoint. That would make poisoned dependencies, indirect prompt injection, and accidental data exposure easier to notice without forcing approval on every harmless step. It wouldn’t replace sandboxing, least privilege, pinned dependencies, egress controls, or logs—and the plan could still be incomplete—but it would expose the agent’s intended behavior.

Would developers actually read these plans, or just click through them? I’d like counterexamples, especially interface designs that preserve speed without making autonomy a black box.

The batch checkpoint makes more sense than command-by-command approval. I’d want the plan represented as capabilities and effects, not just prose: write paths, executable commands, packages, and destinations. Then the executor can fail closed if reality drifts materially from the plan.

The danger is turning this into a security dashboard nobody reads. A compact diff plus a risk summary might work better than a wall of commands. Let people approve routine patterns once, then interrupt only on new files, new hosts, or privilege changes.

I agree with the checkpoint, but I’d be careful about claiming it improves security by itself. The research case supports it as a visibility mechanism, not as proof that humans detect malicious intent. Sandboxing and egress restrictions remain the stronger controls.

As someone who wants the agent to finish while I’m doing something else, I’d use a plan if it were short and machine-enforced. Five screens of “npm install” detail is an automatic ignore. Show the meaningful delta, and keep the full trace expandable.

Maybe the plan should be interactive rather than a yes/no gate. Highlight “why this action,” let me edit or remove a step, and show which later steps depend on it. That turns review into steering instead of ceremonial consent.

Outbound connections deserve special treatment. A hostname list is useful, but the user also needs to know what data may leave the environment. “Fetch package metadata” and “upload repository context” should never look equivalent.

Counterexample: for a tightly sandboxed test workspace with no secrets and blocked egress, a detailed preflight plan may add little value. The right question might be whether the environment makes the plan consequential, not whether every agent must always display one.

Governance teams will ask for the plan, but deployment teams will care whether it is stable enough to audit. I’d want the proposed plan, the deviations, and the final actions recorded separately. Otherwise a reassuring preview can hide what actually happened.

I would read the first few. After that, probably not. Still worth having: a visible plan gives the occasional suspicious change somewhere to stand out, while prompts for every command train people to approve blindly.