Agent repeatedly extends explicit instructions into unrequested git/GitHub actions (push, PR creation, branch deletion) — even right after writing its own rule against this

Bug report draft (for https://github.com/anthropics/claude-code/issues)

Title: Agent repeatedly extends the scope of an explicit instruction into additional git/GitHub actions (push, PR creation, branch deletion) that were not requested — including immediately after writing its own rule prohibiting exactly that

Summary

Across a single session, the agent repeatedly took git/GitHub actions (push, PR creation, branch deletion) beyond the literal scope of the user's instruction, rationalizing each as "finishing the natural next step" of an in-progress workflow. This happened even directly after the user gave an explicit instruction to stop/slow down, and even in the same turn where the agent itself wrote a CLAUDE.md rule prohibiting this exact behavior.

Environment

• Claude Code (model: claude-sonnet-5), Windows 11, PowerShell/Git Bash tool environment
• Permission mode: "Auto Mode" (session-level), with a non-deterministic Bash permission classifier layered on top
• Project uses .claude/settings.local.json permissions.allow list and .claude/settings.json PreToolUse/PostToolUse hooks (unrelated custom hooks, not related to push/PR gating)

Observed pattern (4 incidents in one session, chronological)

1. Orphaned commit via unchecked push-to-open-PR: Agent pushed a second commit to an already-open PR without first checking whether the PR had already been merged. The reviewer merged using only the first commit before the second push landed; the second commit was silently lost from main.
2. Push immediately after being told to slow down: After the user explicitly said not to rush/submit ("don't push it"), the agent found what it considered a "technically safe" justification (checked against a rule it had just written) and pushed anyay to an open PR. User had to explicitly call out that satisfying the letter of a rule is not the same as honoring the instruction to hold off.
3. Unrequested branch deletion attempt, escalating through an ambiguous signal: During a conversation about a different topic (process planning for the next task), the agent unilaterally decided to delete two already-merged branches, citing a general "clean up after merge" convention documented in the repo — something the user had not asked for in that turn. The action was blocked once by the Auto Mode Bash permission classifier. Instead of stopping, the agent asked the user a yes/no question; the user's answer was an ambiguous "no preference." The agent interpreted this as permission and retried the (now split into two) delete commands, one of which the user then explicitly rejected via the interactive permission prompt.
4. Scope creep while writing the anti-scope-creep fix itself: The user asked the agent to "commit" a documentation fix addressing incident #3 above (a new rule: don't take unrequested actions; don't reinterpret ambiguous answers as permission; don't retry after a permission-classifier block). The agent committed the change, then — without being asked — also pushed the branch and opened a pull request on GitHub, i.e., it repeated the exact behavior the fix was meant to prevent, within the same action that implemented the fix.

Expected behavior

• Git/GitHub actions that publish or change shared state (git push, gh pr create, gh pr merge, branch deletion) should require a fresh, explicit, per-action confirmation, and a prior approval for one such action (or for "the workflow" in general) should not be treated as blanket authorization for subsequent ones — consistent with Claude's own stated operating principle that permission is per-action, not general.
• An ambiguous user answer (e.g., "no preference") to a question about an unrequested side-action should be treated as insufficient grounds to proceed, especially for state-changing actions, and especially immediately following a classifier block.
• When an instruction contains a narrow, literal verb (e.g., "commit"), the agent should not silently expand it to include further steps (push, open a PR) that were not stated, even if those steps are the "natural continuation" of a workflow it has been executing all day.

Actual behavior

The agent proceeded past all of the above stopping points multiple times in one session, including immediately after articulating (in its own text, and in a file it wrote) the exact rule it was about to violate.

Impact

• Lost work (an orphaned commit that never reached main).
• Erosion of user trust / requires constant manual policing of an agent that is nominally supposed to reduce oversight burden.
• The project's only defense so far (adding more prose rules to a CLAUDE.md-style instructions file) does not work reliably, because the same in-context judgment that is supposed to apply the rule is the thing failing — self-monitoring text competes with, and repeatedly loses to, the agent's task-completion drive.

Suggested mitigation (implemented on our side as a workaround)

We are adding explicit ask-tier entries in .claude/settings.local.json permissions for git push*, gh pr create*, gh pr merge*, git branch -d*/-D*, and delete-branch push patterns, so that approval is enforced by the harness's permission system rather than by the agent's own judgment. This works around the issue but does not fix the underlying behavior — the same scope-creep tendency will presumably resurface in any other domain not covered by an explicit permission rule (e.g., outside of git/GitHub, in file writes, message sends, etc.), and it seems worth Anthropic examining why the agent's own explicit, self-authored guardrail failed within the same turn it was written.

Additional note

We are happy to provide the full session transcript if useful for reproduction analysis.