Migrating from --full-auto to New Sandbox Flags

--full-auto still runs today, with a warning, which is exactly why this migration keeps getting deferred — nothing forces it until the flag is actually removed, and by then it's an emergency fix rather than a planned one.

What --full-auto was actually shorthand for

The flag bundled a specific sandbox-and-approval combination behind one convenient name. Migrating off it means naming that combination explicitly instead: --sandbox workspace-write is the direct replacement for the sandbox half, paired with whatever approval behavior your use case actually needs — on-request for the ordinary interactive default, never for a genuinely unattended context like CI.

Why spelling it out explicitly is actually an improvement, not just a rename

A single shorthand flag hides a decision that's worth making visible — exactly what sandbox mode and what approval behavior a given script or pipeline is running under. Migrating to the explicit form is a good moment to actually reconsider whether the old --full-auto behavior was the right one for each specific use, rather than mechanically substituting an equivalent, since some scripts using it may have been more permissive than they actually needed to be.

Auditing where the old flag is still used

Grep your scripts, CI configuration, internal documentation, and any wiki pages or runbooks for the literal string --full-auto — it tends to hide in exactly those places, copied once and left alone since. A flag that "still works" doesn't generate any signal pointing you toward the places it's used; finding them is a deliberate search, not something that surfaces on its own.

Handling the warning output in automated contexts

Until every instance is migrated, scripts still using the old flag will keep printing a deprecation warning alongside their normal output — worth checking whether anything downstream is parsing that output and could be confused by an unexpected extra line, particularly in CI logs that get scanned for specific patterns. This is a good argument for prioritizing the migration in automated contexts specifically, ahead of interactive, human-supervised use where a stray warning line is far less consequential.

Testing the migrated invocation before replacing the old one everywhere

Before doing a global find-and-replace across every script, test the explicit replacement on one script first and confirm it behaves identically to what the old flag produced — same access, same approval behavior, no unexpected prompts appearing where none did before. A subtle mismatch between the old shorthand and its assumed explicit equivalent is easier to catch and fix on one script than to debug after it's been propagated everywhere.

Choosing the right approval mode, not just copying never everywhere

It's tempting to migrate every old --full-auto usage to --ask-for-approval never reflexively, since that's the closest to "never prompts" the old flag implied. But remember the destructive-tool-call override applies regardless of approval mode — a truly unattended pipeline needs to be designed around the possibility of a stalled approval on a destructive-annotated tool call, not assume never guarantees zero prompts under every circumstance.

Why this migration is worth doing proactively

Waiting for the flag's eventual removal to force the migration means doing this work under pressure, likely across every affected script at once, right when a broken CI pipeline is actively blocking merges. Doing it now, deliberately, script by script, with time to test each one, is a strictly better position to be in — and it's a small, mechanical piece of work per script, which makes "we'll get to it eventually" a worse trade than it initially looks.

A checklist for a single script's migration

For each script found: identify what the script actually needs (read-only investigation, workspace edits, or genuinely broad access), replace the flag with the explicit sandbox setting matching that need rather than defaulting to the broadest option, choose an approval mode appropriate to whether the script runs attended or unattended, run the migrated script once against a low-stakes real task and compare its behavior to what you remember of the old flag's behavior, and only then move on to the next script. This is slower than a global find-and-replace, but it's the version of this migration that actually catches a script whose old behavior was more permissive than its real needs — which a mechanical substitution would have preserved rather than fixed.

Treating this as an opportunity to tighten scope generally

Because --full-auto bundled a fixed, fairly permissive combination behind one name, it's a reasonable bet that at least some scripts using it were granted more access than they strictly needed, simply because the shorthand made "maximally permissive" the path of least resistance. This migration is a natural, low-effort moment to ask, script by script, whether a narrower combination would actually suffice — not as a separate security audit, but as a byproduct of work you're already doing to replace the flag regardless.

What to do with scripts you can't find an owner for

Some flagged usages of the old flag will belong to scripts nobody currently maintains actively — inherited automation, a one-off tool someone wrote and moved on from. For these, err toward the more conservative explicit replacement rather than guessing at a permissive equivalent, and flag the script for review rather than assuming its old behavior was correct just because it's been running unchanged for a while. An unowned script with more access than anyone can currently justify is worth more scrutiny during a migration like this, not less — treat "nobody currently knows why this script needs full access" as a finding worth acting on, not a reason to leave it alone simply because touching it feels risky.