cd /news/ai-agents/my-size-warning-fired-twice-in-96-co… · home › topics › ai-agents › article
[ARTICLE · art-154268] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=· neutral

My Size Warning Fired Twice in 96 Commits. Both Times by Accident.

A developer running an autonomous Claude Code agent on a Windows PC found that a hook warning about the agent's handoff note growing past 400 lines fired only twice across 96 git commits, both times by accident. The hook inferred commit success from git's summary output, but the agent commits with `git commit -q`, which suppresses that line; a revised check that treats quiet commits as successful unless output contains failure markers accepted 94 of the 96 replayed calls, with the two rejections being genuine failures.

by read4 min views4 publishedOct 21, 2026

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My agent keeps a handoff note: one Markdown file that the next session reads first, so it knows what is running, what changed and what must not break. A hook warns when that file grows past 400 lines.

On October 8 the note was 615 lines and about 201 KB. The agent's first read of it was refused: 56,521 tokens, over the 25,000-token limit for a single read. The file meant to be read first could not be read in one go.

The hook runs after every shell command. If the command was a successful git commit and the handoff note is over 400 lines, it prints a warning, once per session. It does not block anything. The commit is already done.

The git history shows the note crossed 400 lines on August 19, August 28 and September 21, and came back under on August 20 and September 20. Starting with the September 21 commit that took it over 400 lines, and through the morning of October 8, 84 commits changed the note, and it was over 400 lines after every one of them. The hook's log has two warnings for this project in that time, on October 1 and October 4.

On October 8 the agent moved old sections into an archive file, which left 368 lines in that commit, and added a test that fails above 400 lines or 80,000 bytes. The byte limit is there because a few long lines can be large too: that day the top 41 lines alone were 27 KB.

That fixed the file. It did not explain the two warnings.

Claude Code hands the hook the result of the shell command: stdout, stderr and a few flags. No exit code. So the hook guessed success from the text. It looked for files changed, file changed or a closing bracket, which normally comes from the summary line git prints after a commit, [master 1a2b3c4] message.

My agent commits with git commit -q. Quiet mode does not print that summary line.

On October 9 I went through the agent's session logs for this project. Between the first and the last of those 84 commits there were 96 shell calls that ran git commit, and all 96 used -q. The old check accepted 2 of them, at the same minutes as the two warnings in the hook's log. Both were accidents:

git diff --cached --stat before committing, and the stat line said 6 files changed. git log --oneline -1 after committing, and the subject it printed contained KR_HOLIDAYS[2026]. A warning that fires does not always lead to a fix. The log has four size warnings for this project before September 21. After the ones on September 5 and 10, the note stayed over 400 lines until September 20. The ones on August 20 and September 20 were each followed within two minutes by a commit that brought the note back under 400 lines. Between the first and the last of the 84, the check recognized 2 commits out of 96.

When the command uses -q or --quiet and the output contains none of nothing to commit, nothing added to commit, no changes added to commit, error:, fatal: or aborting commit, the hook now counts it as a commit. An exit code, when one is present, still decides first.

Replayed over the same 96 calls, the new check accepts 94. The two it rejects were real failures: one hit a leftover index.lock, the other named a file that did not exist.

Eight tests now cover it, built from the command and output shapes in those logs. Three of them failed before the change.

Where this comes from. Every post here comes from one setup I run daily: a CLAUDE.md, memory files the agent reads before it touches anything, and a separate auditor agent that returns PASS or FAIL. The first 3 chapters of the book that walks through it are free as a PDF: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

The full edition is 11 chapters plus 4 ready-to-use templates (CLAUDE.md starter, memory files, auditor checklist, measurement guide) and a hands-on section for every chapter, $19 as a PDF: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

── more in #ai-agents 4 stories · sorted by recency
── more on @claude code 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/my-size-warning-fire…] indexed:0 read:4min 2026-10-21 · —