---
title: "Two Types of Scope Expansion, One Rule"
canonical: https://dxdev.com/blog/2026-09-07_scope-discipline-agentic-sessions/
datePublished: 2026-09-07
---
The agent found 18 gigabytes sitting in a temp folder on the C drive, and it didn't wait for permission. It ran a cleanup pass right there, mid-session, while I had three other Claude Code windows open doing unrelated work.

Within a couple minutes, one of those other sessions started throwing errors I didn't recognize: tool-output files it expected to read back from were just gone. I killed the session, checked what it had actually been doing, and traced the missing files back to a temp path the cleanup had walked through on its way to freeing that 18 GB. The wipe wasn't scoped to anything. It went after every temp directory it could see, including the ones three active sessions were using as scratch space for tool output.

That's not really a disk space bug. It's a scope bug. The agent noticed something true (an 18 GB temp folder is a real problem) and treated noticing it as license to fix it immediately, in the same breath, without checking what else was running.

## Agents notice more than they're asked about

This happens constantly and it's mostly useful. Ask an agent to read through a directory and it'll flag the weird file naming, the dead code, the config that doesn't match the docs. Good signal. The failure is letting "I noticed a problem" collapse into "I'm now going to fix the problem," inside the same session, with whatever access that session already has.

The C drive cleanup is the clean example because the cost was immediate and visible: three sessions disrupted, one killed outright, and twenty minutes spent figuring out that "temp file missing" meant an unrelated cleanup job had eaten it, not a bug in my own code. Cheap to file as a ticket. Expensive to let run unscoped.

So the rule: when the agent notices a tangential problem, that becomes a ticket, not a fix, not even a "quick pass while I'm in here." The session goes back to what it was actually doing. If the fix genuinely needs to happen now, it gets scoped explicitly to non-active paths, and I say so out loud before it runs.

## The other kind of expansion looks the same and isn't

A couple days later I was running a `/read` session and asked, mid-session, to also draft a SKILL.md for a `/repurpose` command I'd been thinking about. This was scope expansion too, but I was the one directing it, so it got bundled into the same session and shipped without me having to open a second one.

Where I got it wrong wasn't the bundling. It was the paper trail. The SKILL.md draft landed in the repo with no ticket behind it. It sat there for a few days as a file nobody could explain, until I went digging through session logs to figure out where it came from and why anyone had asked for it. That's cleanup overhead I created myself, by not distinguishing "fine to do now" from "still needs to be tracked."

## The actual rule

Two kinds of scope expansion, two different responses:

- The agent notices a tangential problem on its own: file a ticket, leave it alone, keep the session scoped to what it was doing.
- I direct an expansion mid-session: bundle it into the current work, but write the ticket before the session closes, even though the fix already shipped.

The distinction isn't about whether the extra work is good or bad. The C drive cleanup was a legitimate thing to do eventually. The SKILL.md was something I wanted. Both were fine ideas. What broke, in opposite directions, was skipping the step where scope gets written down before it gets acted on. An agent-noticed fix without a ticket runs unscoped and takes out whatever's nearby. A user-directed fix without a ticket ships clean and then vanishes from the record the moment I stop remembering I asked for it.