dependabot.yml edits trigger fresh dependabot scans — Claude Code does not warn, multiplies CI cost

Summary

Claude Code iteratively edited .github/dependabot.yml to clean up a dependabot swarm. Each edit triggered a fresh dependabot re-evaluation against the new config, producing additional PRs. Four self-amplifying waves in one session, ~500+ CI job runs that should not have been needed.

Reproduction

1. Private monorepo with weekly dependabot, 5 ecosystems (pip, npm, github-actions, docker × 2), ~14 required CI checks per PR.
2. Monday scheduled scan produces 16 PRs.
3. I ask Claude Code to clean up and reduce future churn (add ignore rules, then switch to grouped, then monthly).
4. Three iterative .github/dependabot.yml edits across the session.
5. Each edit triggers a fresh GitHub-side dependabot run that opens new PRs.
6. Closing PRs in between freed per-ecosystem queue slots that refilled on the next tick.

Result: 16 → 11 → 7 → 8 PRs across four waves in one morning.

Why this is a Claude Code issue (not a dependabot issue)

• The pattern (config edit triggers re-evaluation) is documented GitHub behaviour. Claude Code did not flag it before iterating.
• Each iteration was framed as a "fix" without modeling the second-order effect.
• Each new PR triggers ~14 CI jobs (matrix × required checks). 4 swarms × ~10 PRs × ~14 jobs ≈ 500+ CI runs.
• For users on metered CI minutes, this is real money.

Suggested mitigation

• For config files whose edit triggers external automated re-runs (.github/dependabot.yml, renovate.json, scheduled .github/workflows/*.yml), Claude Code should warn before iterating and prefer one batched edit over iterative refinement.
• Built-in heuristic on these well-known config files: "this edit will trigger a fresh upstream scan; consolidate intended changes into one commit."

Impact

Significant billable CI minutes consumed across a single session. Filing as a quality complaint.