One afternoon, while fixing a Lab site, I asked /boost to run the tests before reporting back. The summary said the suite passed. Then I ran the same command myself, and the build stopped partway through.
The problem wasn't the code. My working tree held a handful of files that git never tracked but the build reads anyway. /boost had finished its verification somewhere those files did not exist.
That gap has nothing to do with how clever the agent is. If you accept "verified" without knowing where the verification happened, what passed wasn't your tree. So let me share how I count the "where" up front.
/boost does not run in your shared working tree
Start with the official description. /boost isn't simply a knob for more thinking. An Orchestrator decomposes the problem, dispatches implementation and investigation workstreams to specialized subagents, and has them run builds and test suites locally before verifying independently. The Boost deep reasoning guide lays out all three phases.
The line people skip is the workspace row in the execution-mode comparison.
| Dimension | Default agent | /boost |
|---|---|---|
| Workspace | Shared working tree | Ephemeral isolated worktrees |
| Verification | Single-pass tool check | Multi-round independent verification |
| Architecture | Single-agent direct loop | Three-phase reasoning hierarchy |
| Horizon | Seconds to minutes | Seconds to hours |
The default agent touches the same tree I'm looking at. /boost does not. Its subagents work in isolated scopes and run build targets there before reporting. The stated benefit is that scratch diffs and verbose debug output never clutter the main conversation — which is the same thing as saying your local mess doesn't come along either.
Some of that mess, in my case, was load-bearing. A build step read a JSON file that a generation script writes, and that file lives under a directory git has been told to ignore. On my machine it had been sitting there for weeks, so I had stopped thinking of it as absent from the repository at all. It only becomes visible again the moment something checks out a clean copy.
Counting what the isolated tree never sees
Rather than guess, I reproduce the same condition locally. Create a fresh tree from HEAD with git worktree, then diff the file listings.
#!/usr/bin/env bash
# worktree-gap.sh — list paths that exist in your working tree but not in a fresh worktree of HEAD.
# usage: ./worktree-gap.sh [path-to-repo]
set -uo pipefail
REPO="${1:-$(pwd)}"
cd "$REPO" || exit 1
git rev-parse --is-inside-work-tree >/dev/null || exit 1
PROBE="$(mktemp -d)"
cleanup() { git worktree remove --force "$PROBE" >/dev/null 2>&1; rm -rf "$PROBE"; }
trap cleanup EXIT
git worktree add --detach -q "$PROBE" HEAD || exit 1
LIST_HERE="$(mktemp)"; LIST_THERE="$(mktemp)"; MISSING="$(mktemp)"
trap 'cleanup; rm -f "$LIST_HERE" "$LIST_THERE" "$MISSING"' EXIT
find . -path ./.git -prune -o -type f -print | sed 's|^\./||' | sort > "$LIST_HERE"
( cd "$PROBE" && find . -path ./.git -prune -o -type f -print ) | sed 's|^\./||' | sort > "$LIST_THERE"
comm -23 "$LIST_HERE" "$LIST_THERE" > "$MISSING"
echo "== paths absent from a fresh worktree (grouped by top directory) =="
awk -F/ '{ print (NF>1 ? $1"/" : $0) }' "$MISSING" | sort | uniq -c | sort -rn
echo
echo "== of those, the ones tracked code or config refers to by name =="
FOUND=0
while IFS= read -r p; do
base="$(basename "$p")"
case "$base" in .DS_Store|*.log|*.tmp) continue ;; esac
SRC="$(git grep -lF -- "$base" HEAD -- . 2>/dev/null | sed 's|^HEAD:||' | grep -v '^\.gitignore$' | head -3 | paste -sd, -)"
if [ -n "$SRC" ]; then
printf ' %s <- %s\n' "$p" "$SRC"
FOUND=$((FOUND + 1))
fi
done < <(awk -F/ 'NF<=4' "$MISSING" | head -200)
if [ "$FOUND" -eq 0 ]; then
echo " (none. paths known only to .gitignore are excluded from the referrer list)"
fi
echo
printf 'total %s paths do not exist in a fresh worktree.\n' "$(wc -l < "$MISSING" | tr -d ' ')"A note on why a worktree and not a plain clone: git worktree add --detach gives you a second checkout backed by the same object store, so it costs almost nothing in disk or time even on a large repository, and git worktree remove --force cleans it up completely. That matters here because you want the probe to be cheap enough to run before every meaningful /boost request, not a chore you do once and forget.
The first half is the raw diff. The second half is the part that matters: each missing filename gets looked up against tracked code and config with git grep. A file that your code calls by name but a fresh worktree does not contain is exactly where isolated verification walks straight past.
I exclude .gitignore as a referrer on purpose. Ignored files almost always appear in .gitignore by definition, so counting it turns every row into a match and the list stops meaning anything.
Running it against a small test repo holding a .env, a generated artifact, a local config file, and installed dependencies gave me this:
== paths absent from a fresh worktree (grouped by top directory) ==
1 public/
1 node_modules/
1 config/
1 .env
== of those, the ones tracked code or config refers to by name ==
config/local.json <- src/load.ts
public/generated/articles.json <- src/load.ts
total 4 paths do not exist in a fresh worktree.node_modules/ and .env show up in the diff but never reach the referrer list — the first gets refilled by reinstalling dependencies, and the second is known only to .gitignore. The two that src/load.ts names, though, were absent while tests ran against them.
What this script misses
Let me be honest about the first version I wrote. public/generated/articles.json did not appear in the second list at all.
The filter depth was the reason. Trying to keep the output short, I had written awk -F/ 'NF<=2', which throws away anything three levels deep. Generated artifacts usually live somewhere like public/generated/, so I had excluded precisely what I most wanted to find. The version above uses NF<=4.
Three limits remain.
| Limit | What happens | What I do about it |
|---|---|---|
| Matching on filename alone | Common names like index.ts produce false matches | Read the referrer column. Distinctive names are the trustworthy ones |
| Environment variables are invisible | Paths passed through env vars never appear in the source text | Read the CI config alongside the output |
| Execution order is unknown | A referenced file may sit on a path no test actually walks | Treat it as a shortlist, not a count |
There is a fourth thing worth saying plainly: the script tells you what is absent, never whether absence hurts. A stale coverage report sitting in your tree is absent from the fresh worktree too, and nobody cares. Reading the referrer column is the part that cannot be automated away.
So this is a hint, not a verdict. Zero rows is no guarantee of safety, and ten rows is no reason to stop using /boost.
Where I draw the line afterward
Looking at that output, I settled into three ways of asking.
When the referrer column is empty, I take the verification at face value. Pure algorithm work and concurrency bugs usually land here: the inputs are in the source files, the tests are in the source files, and nothing outside the repository is required to reproduce the failure. Nailing down an algorithm or chasing a race condition is exactly what this command was built for.
When generated artifacts show up, I fold the generation step into the request itself. It helps to check first whether that step is actually reachable from a clean checkout — if the generation script itself reads something untracked, you have simply moved the problem one level down. I now keep the generation command in a tracked file rather than in my shell history, which is a habit I only formed after being caught out by exactly that. One extra line — run the generation script before the tests — is enough to give the isolated worktree the same premises. In my case that was the step writing content out to JSON.
When secrets or third-party credentials appear, I don't hand verification over at all. I take the implementation and run the tests myself. Whether I delegate verification depends on whether the tree is complete, not on how capable the model is. That line is the one I hold to hardest on the days I'm in a hurry, because a hurried day is when the summary saying "all tests pass" is most tempting to take at face value.
Worth noting: /boost is available on paid plans, and its subagents inherit whatever permissions your workspace already grants. Protected operations still surface an approval prompt, so isolation doesn't loosen anything — the slash command catalog covers that side as well.
None of this is an argument against delegating. The three-phase pipeline genuinely does what the documentation describes, and multi-round independent verification catches things a single pass will not. The point is narrower: verification is only as good as the tree it runs against, and only one of us knows what is in mine.
Run the script against your own repository once and look at what fills the referrer column. Mine stopped me for a moment, because I had not realized how much I was keeping outside of git. You can't draw the line until you've counted.