Subagents ran 73% of my Claude Code shell commands. The risky git commands came from the main sessions.

Two days ago I wrote about replaying two weeks of Claude Code transcripts to count how often my parallel sessions got in each other's way. A reader on Hashnode asked a question I could not answer from that post: how many of those commands came from subagents rather than the session I was talking to?

Claude Code writes a separate transcript for each subagent under <session>/subagents/, so the question has an exact answer. I reran the replay on the latest two weeks (October 27 to November 10) twice, once on everything and once on the subagent transcripts alone, and subtracted.

Who runs the commands

Subagents ran 73% of the shell commands. That matched my feeling about how I use Claude Code: the main session plans and talks to me, and the subagents go off and run tests, builds, searches and renders. The share of commands that a rule would have blocked was almost the same on both sides, about 0.5%.

So far that says nothing interesting. The split by rule does.

What each side does wrong

The subagents' 401 are almost all waiting. 393 of them are a subagent sitting in a loop for a background job it started. The prompt cache expires after about five minutes without a request, so a subagent that polls in the foreground for ten minutes wakes up to a cold cache and writes its whole context again. In my setup a hook was already blocking the poll loops, so the damage was low: 364 of the 393 were stopped before they ran.

Of the 73 risky git commands, 72 came from main sessions. The subagents almost never touched the branch or the index. The main sessions did, in working trees where another session was active around the same time. Take the waiting rules out and the picture flips: main sessions have 78 rule hits and subagents have 11.

Why this split makes sense

When I ask a main session to finish a task, it is the one that commits, switches branches, rebases on main and pushes. Subagents are handed narrower jobs: run this suite, search for that symbol, render these frames. They inherit the git habits of the main session only if they are told to commit, and I rarely tell them to.

That changes where a guard earns its keep. If you only run one session at a time with many subagents, the waiting and RAM rules are the ones that will fire. If you run several main sessions in the same checkout, the git rules are the ones that matter, and the subagents are mostly innocent.

I also expected subagents to be the main source of the "killed another session's dev server" problem, because they start most of the servers. These two weeks do not show that: only five commands killed processes by name, three from subagents and two from main sessions. That is too few to say either way.

Limits of these numbers

This is one person's machine and one person's way of working. The replay reads command text only, so a kill hidden inside a script or an alias is not counted. The "another session was active" test is rebuilt from transcript timestamps per minute, so it can count a session that was open but idle. And subagents share their parent's session identity, so a rule that compares sessions cannot tell a subagent apart from its own parent at run time. The split above comes from the transcript folders, not from the hooks.

Try it on your own transcripts

The replay is bulkhead scan from claude-bulkhead, an MIT Claude Code plugin I maintain. It only reads ~/.claude/projects and sends nothing anywhere. To get the same split, copy only the subagents folders into a separate directory (hard links work) and point --path at it:

bulkhead scan --since 14d
bulkhead scan --since 14d --path ~/subagent-transcripts

If your numbers look different, especially if your subagents do commit, I would like to hear about it.

I used Claude Code to write parts of the scan and to help draft this post. The numbers come from running it on my own transcripts.