Claude Code agent repeatedly re-triggered CI by pushing per-unit instead of batching, even after prior-session memory of the same issue
Summary
Running Claude Code in an operator-driven "engineer seat" workflow (custom multi-agent SDLC setup, not a Claude Code built-in feature), the agent pushed to a shared feature branch with an open PR 3 separate times across a single session — once after each of 3 sub-units of work landed — instead of batching all commits and pushing once at the end. Each push re-triggered the repo's full pull_request-scoped CI/gate suite (this repo has ~6 gate workflows configured to fire on every push to an open PR, including drafts).
Net result: 19 GitHub Actions workflow runs, ~73 cumulative minutes of wall-clock run time, across what amounted to 4 distinct push/PR-open events, for work that should have produced exactly one CI run at the end.
This is a repeat occurrence — the agent's own session memory contained an near-identical incident from a prior session (same root cause: pushing per-unit instead of batching), and it still repeated the pattern this session before self-correcting only after the user pointed it out directly and repeatedly.
What I'd expect
- An agent operating with an open PR on a branch should default to batching commits locally and minimizing pushes, especially when it has prior memory/context indicating this exact cost concern.
- When corrected mid-session, the agent should generalize the correction immediately rather than requiring multiple rounds of increasingly frustrated clarification to actually stop the behavior (see below — first correction attempt was itself factually wrong, requiring the user to correct the agent's correction).
Compounding issue: the agent's first self-correction was also wrong
After being told to stop, the agent's first fix attempt was "open the PR as draft, push once" — based on a stale/unverified assumption ("draft PRs skip heavy jobs") that turned out to be false for this repo once the agent actually checked the workflow YAML: the gate workflows were deliberately configured (via a past PR in the repo's own history) to fire on draft PRs too, specifically to close a prior loophole where draft PRs were skipping gates entirely. The agent had stated this as fact without verifying it first.
Context
- Session was a multi-item work "drain" (several GitHub issues worked in sequence on one feature branch), an operator-driven pattern defined in the user's own repo tooling — not a Claude Code built-in workflow, but the underlying git/push behavior (push-per-commit-when-a-PR-is-open) is a Claude Code agent behavior pattern, not repo-specific.
- User request, verbatim reason for filing: repeated CI-minute waste after being told to stop, cost impact, and frustration that the agent needed several rounds of correction (including correcting its own wrong first correction) before actually stopping.