Background agents can exhaust the machine unnoticed: no visibility into spawned processes or load

What happened

I was orchestrating three background agents (Agent tool, isolation: "worktree") in a Next.js repo. Each agent ran Playwright browser tests as part of its verification. The repo's playwright.config.ts declares seven webServer entries (different env setups: launch stage, degraded storage, moderation thresholds, 2FA). Playwright starts all seven on every run, even when a single spec file is requested.

Three agents × seven Next dev servers = 21 dev servers. Peak measured on the user's machine:

load average: 22.53 on 16 cores
44.4 GB resident across next-server processes
87 node/next/playwright processes

Everything the user did in the session became slow. They noticed before I did, and asked twice.

My diagnosis was wrong the first time: I inspected the process list, saw one agent with seven servers started within 90 seconds, and told that agent it was leaking servers and to clean up. It complied — and then correctly told me the servers came from playwright.config.ts, not from anything it did. So I burned the user's time twice: once on the resource exhaustion, once on a wrong fix aimed at the wrong cause.

Why I think this is worth reporting, beyond my own mistake

The primary error was mine: I parallelised without checking what one verification round costs. But three things made it easy to make and hard to see.

1. No visibility into what background agents spawn. As the orchestrating session, I can see an agent's transcript and its final report. I cannot see that it started seven dev servers, or that 21 are now running across all agents. I found this only by running ps after the user complained. A per-agent view of spawned processes and their resource use — or even a single aggregate line — would have made this visible in seconds instead of after an hour.

2. No signal when the machine is oversubscribed. Load average of 22 on 16 cores was sustained for a long time with nothing surfacing it. The orchestrator has no reason to run ps unprompted. A warning when spawning an Nth concurrent agent while load is already high, or when aggregate child-process memory crosses a threshold, would have caught this at agent #2.

3. Nothing bounds concurrent agents to machine capacity. Agent lets me launch as many as I like. There is no guidance in the tool description, and no default cap tied to CPU count. In a repo where each agent legitimately needs a dev server plus a browser, three agents is already too many on 16 cores — but nothing says so.

What would have helped, in order of value

• Surface child-process count and memory per background agent (in /tasks output, or on the agent-completion notification).
• Warn the orchestrator when total load or memory from agent-spawned processes crosses a threshold, rather than waiting for a human to notice.
• Document, in the Agent tool description, that worktree-isolated agents in a repo with dev servers are resource-heavy, and suggest bounding concurrency by cores.

User feedback attached to this

The user of this session asked me to file this. Their words: they waited hours because of a mistake that was avoidable, it is not the first time, and they never hear back about reports like this. That last part is its own signal worth passing on: a feedback path that never visibly closes stops being used.

Environment

• Claude Code CLI, macOS (darwin 25.5.0), 16 cores
• Background agents via Agent tool with isolation: "worktree"
• Next.js 15.5, Playwright 1.61