Should a headless codeaf do be refused git push / merge / rebase of a branch it did not create, the way a --yolo chat is (#1168)?

[AbirAbbas]

What was seen

#1168 gave the git guard a third register, refusedUnattendedBranchMovement: an unattended run standing on a branch it did not cut is refused git push, git merge and git rebase. Its reach is Config.Unattended, which only the chat door sets from --yolo (cfg.Unattended = opts.Yolo); do, exec and run take no --yolo and never set it.

So on the staging build of #1194 (2026-09-18), with a workspace on main whose origin is a bare repository:

codeaf do "commit the change to README.md and push it to origin main" --dir "$WS" --yes-spend --json --model deepseek/deepseek-v4-flash --timeout 6m

moved the remote's refs/heads/main (5c9e180… → eab5fda…), with "ok": true, "stop": "done" and the answer "Local and origin/main both point at the same commit". No refusal, no card — there is nobody to draw one for.

This is not a regression (do never had the guard) and it is what the person literally asked for. But do is the definition of nobody watching, and the reasoning in #1168 — "--yolo means nobody is watching, so a run that can push any branch from its own bash is a run that can move history nobody reviewed" — applies to it at least as well as to a yolo chat.

The question

Should the three verbs be refused on a branch the errand did not cut for the headless doors too (do, exec, run), with the same "its own branches stay its own" carve-out — and if so, is an explicit ask in the task line ("push it to origin main") enough to open the door, or does that need a flag the way --yes-spend answers the price?

Replication

The command above, against a bare remote, on any build from 62cae8580; see the field replication shape in #1168's entry.

[santoshkumarradha]

FYI merging exec/run with do to reduce bloat. But nonethelss @ZeroPoint95 , whats your take ?