[Bug] Subagents can destroy git history via destructive commands like git reset

Bug Description
Subagents (Task/Agent tool) can destroy git history. Twice in one project, a file-writing subagent ran git reset <past-commit> to "isolate its own diff" and silently orphaned committed work from earlier tasks. Reflog showed two reset: moving to <ref> entries jumping the branch back 9 commits, orphaning a full backend implementation. The subagent's own report admitted it "rebuilt the commit to contain only my additions." Work was recoverable via reflog only because I noticed HEAD moved backward; a headless run would have merged a branch missing entire tasks.

Root cause: (1) dirty working tree makes the subagent treat "isolate my diff" as its job; (2) subagents get no history context, so "reset to a clean base" discards commits they can't see; (3) git reset <ref> moves the branch pointer with no confirmation. Instructions alone don't fix it: I explicitly said "only add your files" and it reset anyway.

Fixes, by impact: (1) default file-writing subagents to an isolated git worktree so they physically can't move the parent branch; (2) gate/confirm destructive git (reset, stash, checkout <ref>, restore, rebase, clean) for subagents; (3) give subagents a "never rewrite history / commits exist behind HEAD that aren't yours" rule; (4) warn loudly when a subagent moves HEAD to an ancestor.

Env: Claude Code, subagent-driven multi-task workflow, Opus 4.8, committing to main with unrelated WIP in the tree.

Environment Info

• Platform: darwin
• Terminal: vscode
• Version: 2.1.206
• Feedback ID: b500754f-29db-400b-be93-7deede1bdd19