[BUG] Repeated Bash tool-call loop during git workflow consumed session limit

Summary

Claude Code entered a repeated Bash/tool-call loop while trying to stage, commit, push a branch, and create a PR. It repeatedly issued no-op timestamp/progress probes, then hit the session/monthly spend limit during /new-chat before producing a handoff. The repo was left with the intended changes still uncommitted.

Environment

• Claude Code: 2.1.158
• Node: v24.16.0
• npm: 11.16.0
• OS: Linux srv1709900 7.0.0-15-generic #15-Ubuntu SMP PREEMPT_DYNAMIC Wed Apr 22 16:06:43 UTC 2026 x86_64 GNU/Linux
• Project path: /home/elliot/code/iepa
• Local transcript file: /home/elliot/.claude/projects/-home-elliot-code-iepa/ec851176-9189-41f7-8707-cb5a604a2c58.jsonl
• Approx time: 2026-05-30 03:06-04:49 UTC

Observed behavior

• Transcript contains 331 Bash tool calls.
• At least 30 Bash tool calls were simple timestamp probes of the form:
• echo s1 $(date +%H:%M:%S)
• echo c1 $(date +%H:%M:%S)
• echo p1 $(date +%H:%M:%S)
• similar flush/gate probes
• The loop occurred around attempted git staging, commit, push, and PR creation.
• Final user command was /new-chat.
• Final assistant/session-limit text included: "You've hit your session limit · resets 5:30am (UTC)" and later "You've hit your monthly spend limit."
• The working tree was left with substantial uncommitted work.

Repo state afterward

• Branch: feat/qa-account-checkout-scenarios
• HEAD remained at af63c05, same as origin/main.
• Intended migration/UI changes were still unstaged/uncommitted.

Expected behavior

Claude Code should detect repeated no-op/progress-probe loops, stop issuing redundant tool calls, and either complete the pending commit/PR or produce a concise failure/handoff before exhausting session or spend limits.

Actual behavior

Claude Code continued repeated Bash/tool activity, failed to complete commit/PR, and then hit the session/spend limit while trying to generate a new-chat handoff.

Impact

Work was recoverable from the git working tree, but the session ended without committing, pushing, creating the PR, or producing a usable handoff. This created risk of lost context and required manual transcript/repo recovery.

Potential contributing factors

• Background workflow/fallback wakeups were used earlier in the session.
• There was known one-turn output lag in the session.
• The workflow involved staging a scoped subset of files while preserving unrelated WIP.

Diagnostics

• I attempted to submit with /feedback from a fresh interactive session. The command accepted the compact report and returned to an empty prompt, but showed no visible confirmation.
• Running claude doctor produced no output for more than 40 seconds and left a running process, which I manually stopped.
• I did not attach the transcript because it contains private project context, but the exact local transcript path above can be used by the reporter if needed.

Request

Please investigate loop detection for repeated Bash progress probes and /new-chat/handoff behavior near session or spend limits.