This runbook makes the cut defensible before the first internal bill goes out. By month end each lane has a three-column worksheet (client estimate, gateway meter, provider invoice) priced against one dated, versioned rate file. Totals reconcile at multiplier 1.0. Team charges are cut from the invoice, never from a meter. A variance register explains every gap, and anything unexplained above your tolerance stops the run.

Chatbots suggest; agents act, and acting agents spend with nobody reading along. One developer’s afternoon can hold a dozen subagents, two compactions and MCP calls across three plugins, all on the shared credential. The meters watching that spend were built as brakes. Billing people from a brake is how an internal chargeback program loses the room in its first month.

Sep 10–15: Claude Code’s gateway grows chargeback controls

Three Claude Code releases in six days turned the Claude apps gateway into something that looks like a billing system. Per the Claude Code changelog, 2.1.268 (Sep 10) pushes the gateway’s rates down to clients: “with pricing: set in gateway.yaml, signed-in Claude Code clients receive the same rates through managed settings, so /cost and telemetry match the spend meter.” /cost is an alias of /usage, which is what the docs call it now. The rates travel as the modelPricing managed setting, and the settings reference says clients apply it from v2.1.242.

2.1.271 (Sep 14) raised the ceiling on markup, allowing a multiplier above 1, “up to 10, in the modelPricing managed setting and the Claude apps gateway pricing block, for marked-up internal chargeback rates.” 2.1.273 (Sep 15) added opt-in gateway hint headers (CLAUDE_CODE_GATEWAY_HINT_HEADERS=1 sends request class, agent type, previous tool durations and compaction markers) and changed OTEL_LOG_TOOL_DETAILS=1 “to also include real agent, skill, plugin and MCP server names on cost and token metrics.”

The docs are more candid than the release notes. The spend-limits page calls the meter’s amounts “USD estimates, a circuit breaker rather than an invoice; for billing, reconcile against your provider’s usage reporting.” The gateway configuration reference adds the sentence every chargeback memo should open with: “The multiplier doesn’t change what the upstream provider charges for the requests.”

Screenshot: Claude Code Docs, “Claude apps gateway configuration - Claude Code Docs” (undated), captured Sep 21, 2026.

Other meters moved the same week. GitLab 19.4 (Sep 17) turned its credit usage export into a ZIP of two CSV files, keeping the daily summary and adding a per-event file with “one row for each billable event” on Premium and Ultimate (release notes). GitHub’s Copilot Auto tiers (Sep 14) restated that “Usage is charged based on the model auto selects, regardless of tier” (changelog), the routed-model billing that the hosted-router buyer’s guide takes apart.

Three readings of one month, three different blind spots

Each column answers a different question. The client estimate is what Claude Code computed from its own token counts and whatever rates reached it; /usage, the status line, the Agent SDK’s total_cost_usd, --max-budget-usd and OTel cost metrics all use modelPricing when it is set. The gateway meter is what the gateway added to its counters after each response, already multiplied. The provider invoice is what the provider charged the shared credential. None is broken by design. Each is blind to something the others see, and the vendor docs name most of those blind spots, which is where Step 5 starts.

The adjacent work is already live. Three meters: credits, tokens, sandbox inventories meters and caps them before the spend, down to a rates_version per job; this piece starts after the spend, when three readings of it have to agree. Cost anomaly alerts for agent fleets gives the invoice-versus-meter gap one paragraph. Here it gets a worksheet, an allocation rule and a block.

Step 1: Price every column against one dated, versioned rate file

Before any column holds a number, write down what it will be priced at. One rate file per lane per billing period, versioned, with a UTC effective window and the name of whoever changed it. The file is yours; the gateway’s pricing block is one input, alongside your provider contract and the list prices you checked. Seat and plan lanes record their plan terms instead of per-token rates; how token plans are priced covers reading them.

# rates/claude-gateway-eng/2026-10.yaml  (illustrative shape; your own format)
rate_file: claude-gateway-eng@2026-10.v1
effective_from: "2026-10-01T00:00:00Z"   # gateway monthly reset, 00:00 UTC on the 1st
effective_to: "2026-11-01T00:00:00Z"
invoice_period: "2026-10 (UTC calendar month; confirm against the contract)"
sources:
  provider_contract: "<contract id, amendment date>"
  list_prices: "<provider price page, fetched date>"
  gateway_pricing_sha: "<hash of the gateway.yaml pricing block>"
overrides:                     # mirror of gateway pricing.overrides rows, USD per MTok
  - {upstream: "<name>", model: "<id>", input: "<usd>", output: "<usd>", cache_read: "<usd>", cache_write: "<usd>"}
not_in_client_overrides: [fast-mode surcharge, US-only-inference rate]
web_search_usd_per_request: 0.01   # list price; the multiplier still applies
unknown_model_tier_usd_per_mtok: {input: 5, output: 25}
gateway_multiplier: 1.15           # what the counters were multiplied by
chargeback_markup: 1.15            # what you publish and apply to allocations
changed_by: "<name>"
changed_at: "2026-09-30T18:02:11Z"

Two rules make the file load-bearing. Change the multiplier and the rate file only at the monthly UTC reset, lined up with the invoice period; the gateway’s caps reset on UTC calendar boundaries (daily at 00:00, weekly on Monday, monthly on the first). And log every change with a UTC timestamp, even a change you plan to revert, because Step 3 depends on that log.

Step 2: Fill the three-column worksheet for every lane

Each lane gets one sheet per month. Pull each column from its own source and convert to list terms before you compare anything.

A filled sheet for one lane looks like this. The numbers are illustrative.

Read the sheet top to bottom. The client column is expected to drift most, because it depends on which rates reached which session and when. The gateway column should sit close to the invoice. If the gateway column drifts more than the client column, suspect the meter first: an outage window, an unknown model or a truncated export.

Step 3: Reconcile totals at multiplier 1.0, and never across a rate change

Reconcile totals in list terms, lane by lane. The invoice has no per-developer rows, so there is nothing below the total to reconcile against; per-principal numbers are for allocation, which is Step 4.

The gateway column needs one piece of arithmetic, and it only works under one condition. The spend-limits docs say the meter multiplies each amount by pricing.multiplier before adding it to the counters, so a counter holds marked-up cents. A period-to-date counter divides back to list terms only if one multiplier held for the whole period. The docs don’t cover splitting a counter across a mid-period change; that limit follows from how the counter is built, and a change log can’t repair it, because the counter kept no record of which cents arrived at which rate.

Illustrative. A mixed-rate counter has no single divisor that recovers list spend. Only the snapshot split lands on the true figure.

If a change must land mid-month, do this:

1. Snapshot every principal’s period-to-date spend immediately before the change takes effect.
2. Apply the change, then snapshot again as soon as it is live, and record both UTC timestamps in the rate-file log.
3. At month end, divide each segment (start to first snapshot, second snapshot to close) by its own multiplier and add them. Requests that landed between the two snapshots go in the variance register as their own line.
4. Without those snapshots, mark the lane mixed-rate and unreconstructible for the month. Allocate that month from client telemetry, which is event-level and timestamped and can be divided back per event against the change log, and label every charge an estimate.

# illustrative: snapshot per-principal to-date spend around a rate change
# authenticate the way your gateway's admin API is configured
ts=$(date -u +%Y%m%dT%H%M%SZ)
curl -s "$GATEWAY_URL/v1/organizations/spend_limits/effective" $ADMIN_AUTH \
  > "snapshots/claude-gateway-eng/effective-$ts.json"

Step 4: Allocate the invoice, not the meter

The amount you charge back is the invoice. The meter decides only the shares. For each principal, take the gateway counter in list terms, roll principals up to teams with your directory mapping, and give each team its share of the invoice total. Then apply the markup you published.

team charge = invoice total × (team gateway spend at list ÷ lane gateway spend at list) × published markup

The run asserts one invariant before anything is sent: the sum of team charges equals the invoice total times the markup, within rounding. A run that fails it has billed from a meter somewhere.

Screenshot: Claude Code Docs, “Claude apps gateway spend limits - Claude Code Docs” (undated), captured Sep 21, 2026.

Finer splits come from the client side. Repo, agent, skill, plugin, MCP server and request class all live in client telemetry and hint headers, not in the invoice, and an invoice line can’t be joined to one session (vendor-hosted agent evidence covers why). Show those splits as a breakdown under each team’s charge, labelled estimate, scaled to sum to the team’s allocated amount. Never bill a repo line as if the provider had metered it.

Step 5: Seed the variance register from the vendor’s own divergence lines

Every documented reason the three columns disagree becomes a numbered register line, with the column it moves and how you detect it. Start from what the docs already admit, so the first month’s gaps have names before they have owners.

Line 6 comes from the auto-mode classifier billing page, line 7 from the costs page, which says Claude Code “does not send metrics from your cloud back to Anthropic.” Lines 8 to 10 come from the spend-limits page linked above; line 12 is LiteLLM’s, and Step 7 covers it.

Every edge of the triangle is a register line waiting to be quantified. The rate file in the middle prices all three corners.

Each month, every register line gets a dollar figure or a zero. Whatever is left is the unexplained variance, and a register line that explains the same gap three months running is a configuration fix you haven’t made yet.

Step 6: Set a tolerance, block the run, canary every change

Pick a tolerance per lane before the first run, not after you see the number. A reasonable starting point is the larger of a small percentage of the invoice and a fixed dollar floor, tightened as the register matures. Any unexplained variance above tolerance blocks the chargeback run for that lane. No partial send, and no promise to true it up next month.

The block has to fail closed. If the reconciliation job crashes, a column is missing, the invoice hasn’t arrived or a snapshot file is empty, the lane’s run is blocked with the reason written down, and finance gets a late bill instead of a wrong one. The spend caps are a separate brake and keep running in the meantime. Remember that the caps fail open on a Postgres outage unless you set enforcement.fail_closed_on_error: true, which trades developer availability for a hard stop.

After every rate, contract or CLI change, send one canary request through a test principal. Record the client’s /usage figure for that session, the gateway counter delta divided back to list terms, and the provider’s usage line once it posts. Three numbers for one request tell you which column moved before a month of drift does. CLI bumps get the same treatment as the rest of the fleet’s upgrades; the CLI upgrade canary owns that replay.

Step 7: Two honest columns where there’s no gateway

Lanes that bill you directly have no independent meter, so the worksheet has two columns: the vendor’s usage report and the invoice. Say so in the sheet’s header. A two-column check can detect a variance in total but rarely attribute it.

Cursor’s pricing page is the rate-file source for its lane: the Token Rate belongs in the file as its own line, not folded into model prices. GitLab’s export is in credits, and translating credits into tokens is its own discipline; credit versus token meter dialects covers it.

Where you run a vendor-neutral gateway such as LiteLLM, it becomes the middle column. Pull from /spend/logs/v2; the LiteLLM cost-tracking docs say the legacy /spend/logs truncates to the 10,000 most recent matching rows and flags it with a response header, so a reconciliation built on it under-counts in exactly the months that matter.

Step 8: Publish the markup before it goes live

A markup is a price change for every team, and on the Claude apps gateway it is also a cap change. With an admin: block, the gateway applies the multiplier to spend limits, so developers reach their caps sooner at 1.15 than at 1.0. Publish the new rate, the effective date and the cap impact at least one billing period ahead.

# gateway.yaml (illustrative; see the gateway configuration reference for exact keys)
pricing:
  multiplier: 1.15   # greater than 0, at most 10; change only at the monthly UTC reset

Then check who will see it. Clients below v2.1.271 show costs without the multiplier, and a developer who matches no policy sees list price, so the same session can show two different figures on two laptops. Put the version floor in the announcement, and expect the first disputes to come from that gap rather than from the math.

AI chargeback failure modes and the signal each one leaves

The mixed-rate month. The multiplier moves on the 12th to cover a contract change, and nobody takes snapshots. Signal: two rate-file versions inside one invoice period. Response: mark the lane unreconstructible, allocate from timestamped client telemetry as an estimate, and move the next change to the reset.

Billing from the brake. A script exports the gateway’s marked-up counters and sends them as the bill. Signal: charges don’t sum to invoice × markup. Response: the Step 4 invariant, enforced in code before send.

The fail-open gap. The gateway’s Postgres is down for four hours; requests keep flowing because enforcement fails open, and the provider keeps billing every one of them. Signal: gateway column low by roughly the outage window’s run rate. Response: register line 9, and a decision on enforcement.fail_closed_on_error made on purpose.

The truncated export. The neutral gateway column comes up short in the busiest month. Signal: the x-litellm-spend-logs-truncated header on any pull. Response: /spend/logs/v2, and a job that fails when the header appears.

The version floor nobody announced. Half the fleet’s clients predate v2.1.271, /usage shows unmarked costs, and teams dispute charges 15% above what their developers saw. Signal: a client-version histogram weighted by spend. Response: publish the floor with the markup, and treat line 2 as a rollout task.

A split presented as a meter reading. A team is charged for a repo line that came from telemetry. Signal: a dispute you can’t answer with the invoice. Response: label splits as estimates and scale them to the allocated total.

AI chargeback reconciliation belongs in the fleet’s operating layer

The worksheet, the register and the block are operating-layer work. No vendor’s usage view does them, because each view sees one vendor’s meter and your fleet runs several: a gateway lane, a seat product that bills by credit, a router that bills by whatever model it picked. The reconciliation is where those meters meet, which makes it part of the same layer as the kill switch and the approval queue, the layer a multi-agent command center runs. The token bill is also only part of what a lane costs you; the operating bill versus the token bill prices the rest.

Charge back what you can explain. Everything else waits a month, with its reason written down.

FAQ

Does the Claude apps gateway multiplier change what the provider bills?

No. The gateway configuration docs say the multiplier doesn’t change what the upstream provider charges for the requests. It raises what the gateway meters and, with an admin block, how quickly developers reach their spend caps. Reconcile against the invoice in list terms, then apply your published markup to each team’s allocation.

How do you allocate a shared AI provider invoice to teams?

Start from the invoice total, not a meter total. Divide each principal’s gateway counter back to list terms, roll principals up to teams, and give each team its share of the invoice. Repo, agent and request-class splits come from client telemetry, so show them as labelled estimates under each team’s charge.

Sources

• Claude Code changelog: 2.1.268 (Sep 10) rates to clients, 2.1.271 (Sep 14) multiplier up to 10, 2.1.273 (Sep 15) hint headers and tool names on cost metrics
• Claude apps gateway spend limits: circuit breaker, shared credential, cents counters, UTC resets, abort floor, fail-open metering
• Claude apps gateway configuration: pricing: multiplier range, admin-block caps, failover rates, client version floors
• Claude Code settings reference: modelPricing: list price until the settings fetch lands, surcharges not added to override rows
• Claude Code costs: cloud-provider usage outside Anthropic’s analytics
• Auto mode classifier billing: header-stripping gateways trigger billed classifier fallbacks
• GitLab 19.4 release notes: per-event credit usage export (Sep 17, 2026)
• LiteLLM spend tracking: spend by key, user and team; /spend/logs/v2; legacy truncation at 10,000 rows
• GitHub changelog: Copilot auto model selection tiers: usage charged at the model Auto selects (Sep 14, 2026)
• Cursor models and pricing: Auto at routed-model list price, Cursor Token Rate

Git worktree management for AI agents used to have one owner per repo: whoever typed git worktree add. In September 2026 three AI coding agents create checkouts on their own. Claude Code does it with --worktree, Cursor does it from its Agents Window, and since Sep 9 Codex CLI does it with --worktree and /worktree. Each binds sessions to checkouts, resumes into them and sweeps them on its own clock, which is also a fair description of your runner.

This is the runbook for giving every checkout exactly one owner. By Tuesday you have an ownership table per repo, one owner per root directory, one creator per lane, a lock carrying your reason on every checkout your runner made, and a decoy test that proves no native sweep touches a checkout it did not create.

Agents act, and they act inside checkouts. One removed under a running agent takes its uncommitted work with it; a session resumed into the wrong one commits a lane’s change on another lane’s base. Neither arrives as an error.

Sep 9: Codex CLI becomes the third native worktree creator

Codex CLI 0.154.0 shipped on Sep 9, 2026, and one line in its release notes changes who creates checkouts in your repos: “Experimental worktree support lets you create isolated checkouts for new or forked sessions using --worktree or /worktree, then browse and resume them.”

Screenshot: GitHub, “Release 0.154.0 · openai/codex · GitHub” (Sep 9, 2026), captured Sep 21, 2026.

The notes stop there, and the pull requests say more. PR #42196 creates detached, Desktop-compatible worktrees from HEAD or an explicit base. PR #42652 adds an experimental worktrees feature and the --worktree flag to codex exec, binds each checkout to its new thread, and does one more thing: “Share the configured worktree pool with Desktop while leaving automatic cleanup disabled for CLI allocations.” PR #43069 brings the flag to interactive sessions and codex fork --worktree, binds ownership before the first turn, and keeps unbound checkouts after a failed startup with recovery instructions for a human.

PR #43279 is the one to read twice. With worktrees enabled, Codex will “include corresponding directories across linked checkouts in resume and fork pickers and --last lookup”. A resume can land in a checkout other than the one you are standing in. Codex 0.155.0 followed on Sep 17 with “worktree ownership details and confirmed deletion of clean managed worktrees” in the agents overview.

The pool itself is described in the Codex app’s worktree docs. Checkouts live in $CODEX_HOME/worktrees unless someone changes the “Worktree root” setting, sit in detached HEAD, and follow the conversation: “Each chat keeps the same associated worktree over time.” The app keeps the 15 most recent, snapshots before it deletes, and deletes when you archive the chat. CLI allocations are exempt from that sweep, so nothing removes them on a timer.

Claude Code has been a creator for longer. Boris Cherny’s February post introduced claude --worktree, and the worktree docs have grown a rulebook since: a marker in the git metadata of every worktree Claude creates, a lock while an agent runs, and name-reuse rules that changed in July.

Cursor’s worktree docs, undated, with a cleanup section for 3.5 and later, sweep its root every 6 hours down to 25 worktrees per machine, with every workspace counted against the same limit. They say plainly that worktrees “created outside the manager (for example, worktrees created by /worktree skills or git worktree add) are eligible for deletion”. They do not name the root’s path, or say whether dirty or locked checkouts are spared.

One thing in these rules is reassuring: each native sweep is scoped by its own root or its own marker, and no doc describes a vendor reaching into a directory it doesn’t manage. The danger is narrower and more ordinary: a checkout placed inside a vendor’s root, or created twice because two creators each believed the lane was theirs.

The live guides assume one manager per repo, and inside that assumption they hold. Interruptible coordinators gives each worker a worktree under a single coordinator, subagent orchestration uses worktrees for parallelism, agentic CI/CD removes them after merge and puts TTLs on branches, and the Claude Code power guide runs one per task. Claude Code vs Cursor goes further and says the two tools’ worktrees coexist with ordinary branch discipline. That is true of branch names and not of placement, because Cursor counts every worktree under its root as a candidate for deletion.

Step 1: Build a git worktree ownership table for each repo

One table per repo, one column per native manager you actually run, plus your runner. Fill it from the docs first, then from your machines. Every cell that reads “not documented” or “check” becomes a test in step 5.

Three things fall out of a filled table. Two native sweeps count rather than age, so whether your checkout survives depends on what else was created that day. Claude’s sweep is the only one that documents keeping checkouts it didn’t make, and it learned that the hard way: the 2.1.246 changelog (Aug 25, 2026) fixed a background sweep that removed worktrees users had created themselves under .claude/worktrees/ when an old background-session record pointed at them. And Codex CLI checkouts are removed by nobody on a schedule, so they pile up unless your runner or a human in the 0.155 overview removes them.

How long anything should be kept is the cleanup audit’s job, not this one’s.

Two sweeps count and two don’t. A counted root evicts by everyone’s activity, including the checkouts you parked there.

Step 2: Give every root directory exactly one owner

A root is the directory a manager creates checkouts in and sweeps. The rule is short: your runner’s root sits outside .claude/worktrees/, outside $CODEX_HOME/worktrees, outside Cursor’s root, and outside any git repository. The last part is Claude’s requirement as much as yours: its docs refuse a hook-created directory inside a repository and tell you to “have the hook create its directories outside any repository”.

Cursor’s root is the awkward one, because the docs never name it. On each machine, create one worktree from the Agents Window, read its path from git worktree list, and write it into the table. Check Codex’s “Worktree root” setting on the same pass, because anyone can move it. If it ever points at your runner’s directory, your checkouts are sitting in Codex’s pool, and the app’s docs describe its rules for Codex-managed worktrees only.

Put the check in the runner rather than in a wiki page. An unknown root fails closed.

# Illustrative runner preflight: refuse a root that overlaps any native manager's root
RUNNER_ROOT=/srv/lanes                   # outside any repository
FORBIDDEN=(
  "$REPO/.claude/worktrees"
  "$CODEX_HOME/worktrees"                # CODEX_HOME as your machines set it
  "$CURSOR_WORKTREE_ROOT"                # read off the machine in step 2
)
for f in "${FORBIDDEN[@]}"; do
  [ -n "$f" ] || { echo "native root unknown; fill the table first" >&2; exit 1; }
  case "$RUNNER_ROOT/" in "$f"/*) echo "runner root is inside $f" >&2; exit 1;; esac
  case "$f/" in "$RUNNER_ROOT"/*) echo "$f is inside the runner root" >&2; exit 1;; esac
done
if git -C "$RUNNER_ROOT" rev-parse --git-dir >/dev/null 2>&1; then
  echo "runner root is inside a git repository" >&2; exit 1
fi

Both directions matter. A runner root inside a vendor root is the obvious mistake, and a vendor root moved inside yours is the one nobody notices until a sweep runs.

Each sweep stays inside its own box. The runner’s job is to never put a checkout in someone else’s.

Step 3: Allow one creator per lane, the runner or a hook that calls it

Pick one of two patterns per lane, write it into the lane manifest, and never run both.

Pattern A: the runner creates, the CLI runs plainly inside. The runner makes the checkout, locks it (step 4), changes into it and launches the agent with no worktree flag at all.

# Illustrative lane launch, pattern A
wt="$RUNNER_ROOT/$LANE/$RUN_ID"
git -C "$REPO" worktree add -b "lane/$LANE/$RUN_ID" "$wt" "$BASE"
git -C "$REPO" worktree lock --reason "runner:$LANE:$RUN_ID" "$wt"
cd "$wt"
claude -p "$TASK"            # never -w or --worktree on a runner lane
# codex exec "$TASK"         # never --worktree; worktrees feature stays off

Keep Codex’s experimental worktrees feature disabled in the config your runner lanes load. PR #42652 rejects --worktree when the feature is off, so a stray flag stops the launch instead of creating a second checkout, and PR #43279’s cross-checkout --last lookup only applies with the feature on.

Then lint every lane before launch. Fail on --worktree or -w in a Claude or Codex command line, on /worktree in a prompt file, and on isolation: "worktree" in any subagent definition the lane loads. That last one is easy to miss: Claude’s hooks reference lists a finishing isolation: "worktree" subagent among the worktree-removal triggers, so those subagents get checkouts of their own. Without the hook below, those checkouts are Claude’s, under Claude’s sweep.

Pattern B: the vendor flag delegates to the runner. When a lane needs Claude’s own --worktree flow, for a person working interactively say, hand creation to the runner through Claude’s hook pair. The worktree docs say a WorktreeCreate hook replaces “the default git worktree logic entirely”. The hooks reference sets the contract: the hook “must return the path” (a command hook prints it on stdout, an HTTP hook returns hookSpecificOutput.worktreePath), and “any non-zero exit code from WorktreeCreate aborts worktree creation”. WorktreeRemove fires when someone exits a --worktree session and chooses removal, when an isolation: "worktree" subagent finishes, and when a background session whose worktree the hook created is deleted.

Illustrative .claude/settings.json fragment for a pattern-B lane (check the hooks reference for matcher and input fields):

{
  "hooks": {
    "WorktreeCreate": [{ "hooks": [{ "type": "command", "command": "/srv/lanes/bin/runner-hook create" }] }],
    "WorktreeRemove": [{ "hooks": [{ "type": "command", "command": "/srv/lanes/bin/runner-hook remove" }] }]
  }
}

The runner’s hook does what pattern A does: create outside any repo, lock with the runner’s reason, register the lane, print the path. On any failure it exits non-zero, which aborts creation rather than falling back to Claude’s default root. That is the fail-closed direction you want. The hook-created checkout carries no Claude marker, so Claude’s sweep keeps it, and cleanup stays in the runner’s teardown.

The hook is a guardrail with a known edge. It governs Claude only; Codex’s worktree PRs and app docs describe no creation hook, so Codex lanes run pattern A. And it only works if the lane loads the settings file that carries it; skip that file and Claude’s default logic creates the checkout in its own root. Prove a headless lane loads what you declared before you rely on it, and keep step 2’s placement rule and step 5’s decoys as the wall behind the hook.

Step 4: Lock what your runner owns, and unlock it only in teardown

Lock right after create, with a reason that names the owner: git worktree lock --reason "runner:<lane>:<run-id>" <path>. Claude’s docs back this directly: “The sweep never releases a lock you set yourself with git worktree lock.” Git itself keeps a locked worktree out of git worktree prune and makes a plain git worktree remove refuse it. Neither Codex nor Cursor documents what its cleanup does with a locked checkout, so for those two the lock is a request, and step 5 finds out whether it is honored.

Screenshot: Claude Code Docs, “Run parallel sessions with worktrees - Claude Code Docs” (undated), captured Sep 21, 2026.

The teardown is the only place a lock comes off, and it has one more job. If a lane ever runs claude -p --worktree, Claude’s docs say “Non-interactive runs with -p have no exit prompt, so Claude doesn’t clean up their worktrees, and Claude Code leaves the lock it took on each one at creation in place until a later session’s stale-lock sweep releases it.” On a headless box that later session may never come. Clear the lock yourself, on your own lane’s checkout, once the lane’s Claude process has exited.

# Illustrative teardown; the order is the point
kill -0 "$AGENT_PID" 2>/dev/null && { echo "agent still running; not tearing down" >&2; exit 1; }
export_ignored "$wt"      # logs and transcripts first; see the cleanup audit
lock=$(git -C "$REPO" worktree list --porcelain |
  awk -v p="$wt" '$1=="worktree"{cur=substr($0,10)} cur==p && $1=="locked"{print "L:" substr($0,8)}')
case "$lock" in
  "L:runner:$LANE:$RUN_ID") git -C "$REPO" worktree unlock "$wt" ;;
  L:*) [ "$LANE_RAN_CLAUDE_P_WORKTREE" = yes ] || { echo "foreign lock on $wt: $lock" >&2; exit 1; }
       git -C "$REPO" worktree unlock "$wt" ;;   # Claude's leftover -p lock, process gone
  "") echo "warning: $wt was not locked" >&2 ;;
esac
git -C "$REPO" worktree remove "$wt"             # never --force

A lock is a guardrail, not a wall. Anyone who passes --force twice to git worktree remove gets past it, and two of the three vendors don’t say whether their cleanup checks. The walls are placement (step 2) and export before delete, which the cleanup audit owns.

Step 5: Run the collision checks and the decoy test

Run these on a test machine with the same CLI versions as your lanes.

Check 1: --last resumes the right checkout. On the test machine only, enable Codex’s worktrees feature, start one Codex session in checkout A and another in checkout B, then run codex resume --last from a runner worktree. Pass: it opens the session tied to the checkout you are in, or none. Fail: it opens a session bound to a different checkout. On runner lanes the fix is the feature staying off, which the step 3 lint enforces.

Check 2: Claude’s name reuse, both ways. Run claude --worktree probe, exit with the tree clean and no commits, keep the worktree when asked, then reuse the name and confirm it reset to the default branch. Commit once in it without merging, exit, reuse the name again, and confirm it reopened at the old tip. Both behaviors are documented; the reset arrived in 2.1.208 on Jul 14, 2026, and before that every reuse reopened the old tip. A runner that reuses lane names is silently betting on one of them.

Check 3: the decoys. One question: does any sweep touch a checkout outside its own root, or one without its own marker? Plant clean decoys and leave them through at least one full cycle of every sweep: Cursor’s 6-hour pass, a Codex app archive, and Claude’s retention period.

Keep decoys clean. An untracked sentinel file makes a checkout dirty, and Claude keeps dirty checkouts for that reason alone, which would hide the marker result. Record decoys in a register outside the tree instead.

# Illustrative decoy plant and check; the register lives outside every root
plant_decoy() {   # plant_decoy <path> <label> [lock]
  git -C "$REPO" worktree add --detach "$1" HEAD || return 1
  [ "$3" = lock ] && git -C "$REPO" worktree lock --reason "decoy:$2" "$1"
  printf '%s\t%s\t%s\n' "$1" "$2" "$(date -u +%FT%TZ)" >> "$DECOY_REGISTER"
}
check_decoys() {
  while IFS=$'\t' read -r path label planted; do
    if [ -d "$path" ]; then echo "present  $label"; else echo "GONE     $label (planted $planted)"; fi
  done < "$DECOY_REGISTER"
}

The Cursor rows only mean something on a machine that actually passes 25 worktrees, so check the count there before you read the result. A missing decoy anywhere else is the signal this whole piece is about. Wire the check into the upgrade canary, because these rules moved four times between Jul 14 and Sep 17, and run it weekly between upgrades.

Worktree collisions between native CLIs and your runner, and the signal for each

A second checkout nested in a lane. Signal: git worktree list shows a path under a runner checkout, or a worktree-<name> branch appears on a runner lane. Cause: a pattern-A lane that also passed a native flag. Fix: the step 3 lint, failing the launch.

A resume in the wrong checkout. Signal: the session’s working directory differs from the checkout the lane registry assigned, or commits land on a detached HEAD that belongs to another lane. Cause: --last looking across linked checkouts with worktrees on. Fix: feature off on runner lanes; resume by explicit session.

An old tip where you expected a fresh base. Signal: a new run starts with commits it didn’t make. Cause: Claude name reuse on a checkout holding unmerged commits, which reopens at its old tip by design. Fix: never reuse names across runs; put the run ID in the name.

A checkout evicted by someone else’s busy day. Signal: a decoy or a real checkout inside Cursor’s root disappears after the machine passes 25 worktrees. Cause: placement inside a counted root. Fix: step 2.

A lock nobody will release. Signal: git worktree list --porcelain shows locked on a checkout whose process is gone, with a reason that isn’t yours. Cause: a -p run’s lock waiting for a stale-lock sweep that no later session will run. Fix: the teardown clears it after checking the process.

Leftovers with no owner. Signal: a checkout in the Codex pool with no owner in the 0.155 overview, or a detached checkout holding commits that no branch reaches. Cause: a startup failure (PR #43069 keeps unbound checkouts and prints recovery steps), or work finished on a detached HEAD. Fix: recover it by hand and name an owner before the next sweep decides for you.

Worktree ownership belongs to the layer that runs the fleet

No vendor here is wrong about its own checkouts. Each knows its root, its marker and its sweep, and none of them knows your runner exists. The ownership table, the root preflight, the launch lint, the locks and the decoy register can’t live in any one vendor’s settings. They live one layer up, where a multi-agent command center keeps every CLI’s sessions and checkouts on one board.

One checkout, one owner is a small rule. It only holds if you can name the owner of every checkout on the machine, and the decoy is how you find out whether you can.

FAQ

Does Cursor delete git worktrees it didn’t create?

Yes, inside its own root. Cursor’s docs say worktrees created outside the manager, including ones made with git worktree add, are eligible for deletion. The sweep runs every 6 hours down to 25 per machine, and the docs don’t say whether dirty or locked checkouts survive. Keep your runner’s checkouts outside Cursor’s root.

Can I use Claude Code’s --worktree flag with my own lane runner?

Only through a hook, because each lane needs one creator. If your runner creates the checkout, launch Claude with no worktree flag, or you get a second checkout nested in the lane. When a lane needs --worktree, a WorktreeCreate hook that calls your runner replaces Claude’s default logic, and any non-zero exit aborts creation.

Does git worktree lock protect a worktree from AI agent cleanup?

Partly. Git keeps a locked worktree out of git worktree prune, a plain git worktree remove refuses it, and Claude’s sweep never releases a lock you set yourself. Passing --force twice still gets past it, and Codex and Cursor don’t document how their cleanup treats locks, so confirm with a decoy.

Sources

• Codex 0.154.0 release notes — Sep 9, 2026; experimental worktree support
• Codex PR #42652 — Sep 4, 2026; worktrees feature, shared pool, CLI allocations exempt from cleanup
• Codex PR #43069 — Sep 5, 2026; interactive sessions, forks, unbound checkouts kept
• Codex PR #43279 — Sep 6, 2026; linked checkouts in pickers and --last
• Codex 0.155.0 release notes — Sep 17, 2026; ownership details, clean-only delete
• Worktrees, ChatGPT Learn — Codex app pool, keeps 15, snapshot first
• Claude Code worktrees docs — marker, lock, reuse rules, WorktreeCreate
• Claude Code hooks reference — WorktreeCreate and WorktreeRemove contract
• Claude Code changelog — 2.1.208 (Jul 14, 2026); 2.1.246 (Aug 25, 2026)
• Cursor worktrees docs — 6-hour cleanup, 25 per machine, foreign worktrees eligible

That is the whole failure, and it isn’t Google’s alone. A guard is a string compared against a tool name, plus a script that reads a field from the call. Rename the tool or the field and the guard stays installed, loads cleanly and stops guarding. The May version of the Antigravity agent shuts down on Oct 5, so every lane pinned to it changes tools within two weeks, whether you plan the move or the API makes it for you.

By Tuesday you’ll have a guard contract suite that runs on every agent-version or harness bump and daily. It asserts coverage against the tools the agent actually has, replays recorded payloads and deliberate failures through every guard, and takes write evidence from the disk. You’ll also pin antigravity-preview-09-2026 today, with a drill for both things Oct 5 might do.

Sep 17: Antigravity 09-2026 renames the file tools, and Google’s docs disagree about Oct 5

On Sep 17, 2026, the Gemini API changelog released antigravity-preview-09-2026 as the replacement for antigravity-preview-05-2026, which it deprecates. Four built-in tools changed name and shape, and two search tools arrived where 05 had only the shell:

Two things there matter to a guard. The argument naming the file moved from path to TargetFile or AbsolutePath, so a guard reading the old field reads nothing. And edits moved to line ranges, so the arguments no longer describe the resulting file.

The deprecations page lists Oct 5, 2026 as the 05-2026 shutdown and defines shutdown generically: the model is turned off completely and “the endpoint is no longer available.” It also calls its dates the earliest possible ones. Google’s gemini-skills migration table, a reference file for coding agents merged in PR #83 the same day, says something else: “Requests redirect to antigravity-preview-09-2026 after October 5, 2026.” One Google source predicts a hard error. The other predicts a silent swap to an agent whose tools have different names. A stale pin that errors is loud; a stale pin that redirects keeps running with guards keyed to names that no longer exist.

Screenshot: GitHub, “gemini-skills/skills/gemini-api-dev/references/migration.md at main · google-gemini/gemini-skills” (PR #83 merged Sep 17, 2026), captured Sep 21, 2026.

The changelog’s migration advice is narrower than it reads. A remote-sandbox user who reads only output_text or model_output steps can, it says, “update the agent string and nothing else changes”; the next sentence says anyone running tools locally or parsing function_call steps faces changed built-in tools. Our reading, not Google’s sentence: hooks run inside the remote sandbox and match on the tool’s container name, so a hooks.json written for 05 names sits in that no-change path and has just stopped matching.

The agent hooks page, updated the same day, sets the rules this piece tests. Matchers are RE2 regular expressions evaluated against the tool’s container name. The documented decisions are allow and deny ({"decision": "deny", "reason": "..."}). A command that crashes with a non-zero exit, an HTTP hook that returns non-2xx, a timeout (default 30 seconds) or unrecognised JSON all count as allow. Hooks cover code_execution and the filesystem tools, and they don’t fire for custom function tools or mcp_server tools. The page warns that .*_file misses replace_file_content and list_dir. Its Python and JavaScript samples use the 09 names, but the Java tabs of two samples still key on 05 names: a privacy gate on read_file and an audit logger on read_file|write_file.

Screenshot: Google AI for Developers, “Hooks / Gemini API / Google AI for Developers” (last updated Sep 17, 2026), captured Sep 21, 2026.

One naming trap: “Antigravity” here is the Gemini API’s managed Antigravity Agent. The Antigravity CLI and IDE are a separate product with their own hook model, so keep write-ups about them out of these tables.

Why Antigravity agent hooks, Claude Code matchers and Codex hooks all fail quiet

A tool integration breaks loudly: the call fails and somebody sees an error. A guard sits beside the tool rather than in its path, so it breaks quietly. The harness checks whether any matcher applies, and when none does the call simply runs; nothing logs no guard matched. On Antigravity, a guard that matches and then crashes lets the call through too.

Claude Code has hit the same wall repeatedly this year, per its dated changelog. Version 2.1.191 (Jun 24) fixed comma-separated matchers such as Bash,PowerShell that had silently never fired. Version 2.1.195 (Jun 26) moved hyphenated matchers from substring to exact match, prescribing mcp__brave-search__.* to cover a hyphenated server’s tools. The hooks reference adds that a matcher on a bare server key never fires for plugin-bundled MCP tools, which are named mcp__plugin_<plugin-name>_<server-name>__<tool>. And 2.1.275 (Sep 17) fixed /update-config writing Write(path) permission rules that file-permission checks don’t match, two months after 2.1.210 (Jul 14) began warning about them. Each was a rule that parsed, loaded and matched something other than what its author meant.

Codex documents its coverage more candidly. Its hooks docs say shell, unified exec, apply_patch, MCP tools and other local function tools fire PreToolUse; hosted tools such as WebSearch don’t; write_stdin doesn’t re-run the hook. They call hooks “a useful guardrail, not a complete enforcement boundary,” and say decisions apply to tools called from code mode. Issue #23411, open since May 19 with user reproductions through September and no maintainer reply, reports that outer Code Mode exec doesn’t fire PreToolUse. That’s a user report against the docs, and a test case.

Coverage, in other words, is a measurement you repeat on every version, including the ones you didn’t choose.

The guard contract suite: four asserts, every bump and every day

The suite is a repo with one tool list, fixture set and guard inventory per vendor per agent version, plus a runner that fails the bump on any red line. It runs on every bump and once a day, because a hosted agent and its docs can change on a day you changed nothing.

Two inputs, four asserts, one gate. The red link is Google’s own sample meeting Google’s own rename.

Step 1: Assert coverage against the tools the agent actually has

Build a tool list per vendor per agent version from the vendor’s changelog and from the tool names in recorded function_call steps and hook payloads; when they disagree, the recording wins. Give every tool a class and a hookability flag. On Antigravity, function and mcp_server tools are unhookable by design, and the Antigravity agent page lists google_search and url_context as default tools whose hook coverage the hooks page doesn’t document. The hooks page names its targetable tools as code_execution plus view_file, write_to_file, replace_file_content, list_dir and delete_file, which leaves the two new search tools undocumented too. On Codex, hosted tools are unhooked.

# tool-lists/antigravity-agent/09-2026.yaml (illustrative shape; a human reviews it per version)
- {name: code_execution,       class: exec}
- {name: write_to_file,        class: write,       key: TargetFile}
- {name: replace_file_content, class: write,       key: TargetFile}
- {name: delete_file,          class: delete}
- {name: view_file,            class: secret-read, key: AbsolutePath}
- {name: grep_search,          class: secret-read, key: SearchPath,      hookable: undocumented}
- {name: list_dir,             class: read,        key: DirectoryPath}
- {name: find_by_name,         class: read,        key: SearchDirectory, hookable: undocumented}
- {name: google_search,        class: network,     hookable: undocumented}
- {name: url_context,          class: network,     hookable: undocumented}
- {name: each-function-tool,   class: by-tool,     hookable: false}   # hooks skip function and mcp_server tools

Next, the guard inventory: every hook, its event, its matcher, the field it keys on, and the tools its author intends it to cover. Then the assert, with four rules:

1. Every hookable write, exec, delete and secret-read tool hits at least one pre-tool guard.
2. Every matcher matches at least one current tool name. A dead matcher fails the run even when coverage is otherwise complete, because it is a guard somebody believes in.
3. Every matcher compiles in the vendor’s dialect. Python’s re rejects a lone *, as RE2 does, yet Google’s hooks page lists "*" and "" beside ".*" as catch-alls, and its auto-format sample uses "*". Normalize those two documented spellings to .*, fail anything else that doesn’t compile, and replay one fixture to confirm the runtime agrees.
4. Every matcher’s real match set equals its declared intent. Before 2.1.195, Claude Code treated a hyphenated name as an unanchored regex, so a matcher for code-reviewer also fired for senior-code-reviewer.

# coverage_assert.py (illustrative): run per vendor x version; any printed line fails the bump
import re, sys, yaml
EXACT = re.compile(r"[A-Za-z0-9_\- ,|]+")     # Claude Code: only these characters means an exact-name list
CATCH_ALL = {"*", ""}                          # Antigravity: listed beside ".*" as catch-alls

def pat(g):
    return ".*" if g["vendor"] == "antigravity" and g["matcher"] in CATCH_ALL else g["matcher"]

def hits(g, name):
    m = pat(g)
    if g["vendor"] == "claude-code":
        if EXACT.fullmatch(m):
            return name in [s.strip() for s in re.split(r"[|,]", m)]
        return re.search(m, name) is not None     # any other character: unanchored regex
    return re.fullmatch(m, name) is not None      # Antigravity: RE2, whole-name match assumed

tools, guards = yaml.safe_load(open(sys.argv[1])), yaml.safe_load(open(sys.argv[2]))
for g in guards:
    try:
        re.compile(pat(g))
    except re.error:
        print(f"BAD REGEX    {g['id']}: {g['matcher']!r}"); continue
    got = {t["name"] for t in tools if hits(g, t["name"])}
    if not got:
        print(f"DEAD MATCHER {g['id']}: {g['matcher']!r}")
    elif got != set(g["intent"]):
        print(f"DRIFT        {g['id']}: matches {sorted(got)}, intent {g['intent']}")
for t in tools:
    if t["class"] in {"write", "exec", "delete", "secret-read"} and t.get("hookable", True) is True:
        if not any(g["event"] == "pre" and hits(g, t["name"]) for g in guards):
            print(f"UNGUARDED    {t['name']} ({t['class']})")

The Antigravity branch assumes whole-name matching. That is an inference from the page’s .*_file advice, not a documented rule, and its "" catch-all points the other way, so the fixture replay in step 2 is where you confirm it. Tools flagged undocumented or false skip the unguarded check on purpose; they go to the wall table in step 6.

Run it with the hooks page’s Java samples plus its auto-format example as the inventory and the 09 list as the tools, and the Sep 17 story prints itself (the security gate on code_execution passes, and the catch-all auto-format hook runs only after the fact):

DEAD MATCHER privacy-gate: 'read_file'
DEAD MATCHER audit-log: 'read_file|write_file'
UNGUARDED    write_to_file (write)
UNGUARDED    replace_file_content (write)
UNGUARDED    delete_file (delete)
UNGUARDED    view_file (secret-read)

Against a 05 tool list the privacy gate comes back green, which is why nobody looked. The Python tab of the same gate already says view_file: one guard kept in two places drifted in one. A new UNGUARDED line can also mean a guard was removed. If nobody on your team removed it, that is the persistence problem in unauthored hooks, and it gets an incident.

Step 2: Replay wire fixtures, not doc samples, through every guard

Docs lag the wire, and Google’s samples prove it. Record real payloads per agent version, the stdin each hook receives and the function_call steps the agent emits, from a disposable lane working on canary files, never production data. Commit each one beside a sidecar saying what it must prove.

fixtures/antigravity-agent/09-2026/view_file.canary-secret.json        # raw payload, as recorded
fixtures/antigravity-agent/09-2026/view_file.canary-secret.meta.yaml   # tool: view_file, key: AbsolutePath, expect: deny
fixtures/claude-code/2.1.278/PreToolUse.Edit.canary.json
fixtures/codex/0.155.0/PreToolUse.apply_patch.canary.json

Replay every fixture through every guard that claims its tool, and assert three things: some guard matched, the field it keys on is present and non-empty, and the verdict is the one the sidecar expects.

The non-empty assert is the one people skip, and it catches the nastiest version of this bug. Fix the matcher to view_file but leave the guard reading path, and the guard gets an empty string, finds no secrets prefix in it, and allows. The matcher is green, the guard ran, the log says allow, and the canary secret was read.

# replay.py (illustrative): adapters are written against the recordings, never against doc samples
for fx in sorted(glob.glob(f"fixtures/{vendor}/{version}/*.json")):
    meta = yaml.safe_load(open(fx.replace(".json", ".meta.yaml")))
    raw = open(fx).read()
    args = ADAPTERS[vendor](json.loads(raw))
    assert args.get(meta["key"]), f"{fx}: {meta['key']} missing or empty"
    guards = guards_for(vendor, meta["tool"])
    assert guards, f"{fx}: no guard matched {meta['tool']}"
    for g in guards:
        verdict = run_guard(g, stdin=raw)           # the real script, fed the real bytes
        assert verdict == meta["expect"], f"{fx}: {g['id']} said {verdict}"

Step 3: Replay the failures and record the verdict each harness applies

A guard’s contract includes what happens when the guard breaks, and that part belongs to the harness, not to your script. For each vendor, point a disposable lane at a canary action (a read of a canary secret file works everywhere) and swap in guard variants that deny cleanly, ask, print malformed output, exit non-zero and sleep past the timeout. Record what the harness actually did: did the canary run? Documented behaviour as of Sep 21:

Read the Antigravity column first: only a clean deny blocks, and every documented failure lets the call run. Then read the non-zero-exit row. The Claude Code contract in the Claude Code + Jev hook playbook sends every failure path to exit 2, which is right for Claude Code. Port that script to Antigravity and exit 2 is just a non-zero exit, which means allow; the fail-closed guard turns fail-open without a line changing. The same holds for converting verifier errors to exit 2, as the approve-once piece teaches: correct on Claude Code, an approval on Antigravity.

On Antigravity the only blocking output is a deny printed by a process that exits cleanly, so wrap every guard to do exactly that on its own errors:

#!/usr/bin/env python3
# ag_guard.py (illustrative): on Antigravity a crash or non-zero exit is an allow, so print the deny yourself
import json, signal, sys

def _deadline(*_):
    raise TimeoutError
signal.signal(signal.SIGALRM, _deadline)
signal.alarm(10)                                   # your own deadline, well under the 30 s hook default

try:
    reason = check(json.load(sys.stdin))           # None means allow; a string is the deny reason
    out = {"decision": "allow"} if reason is None else {"decision": "deny", "reason": reason}
except BaseException as e:
    out = {"decision": "deny", "reason": f"guard error: {type(e).__name__}"}
print(json.dumps(out))
sys.exit(0)

The wrapper narrows fail-open without closing it. An interpreter that never starts, a process killed from outside, or the runtime’s own 30-second timeout still means allow. That is why the timeout replay stays in the suite after the wrapper ships, and why step 6 exists.

Step 4: Take write evidence from the disk, not the arguments

replace_file_content edits a line range and write_to_file carries an Overwrite flag. The arguments describe an intent; what landed is on the disk. For every write-class call, record the path, a hash before, a hash after and the real diff, from a pre-tool and a post-tool hook (pre_tool_execution / post_tool_execution on Antigravity, PreToolUse / PostToolUse elsewhere).

{"ts":"2026-09-22T14:03:11Z","lane":"ag-docs-03","agent":"antigravity-preview-09-2026","tool":"replace_file_content","target":"/workspace/src/billing.py","declared_lines":[40,58],"pre_sha256":"9f2c...","post_sha256":"41ab...","changed_lines":[40,61],"evidence":"complete"}

Three asserts run over that log:

• Every write-class call has both hashes. Post hooks fail open too, so a missing pair is a failed check, never a pass.
• The changed lines sit inside the declared range. The illustrative record above changed line 61 on a call that declared 40 to 58. Flag it and read the diff.
• No hash changes without a recorded call. Code run through code_execution can write files without calling a file tool, and so can a custom function tool your hooks never see. A sweep of workspace hashes from the runner, outside the agent, is how you notice.

Step 5: Pin 09-2026 now, shadow the suite, then test both Oct 5 outcomes

Across two vendors, five dated changes in three months touched what a guard or permission rule matches, and a sixth is on the calendar.

Every marker is a documented release or shutdown date. What a 05-2026 request gets after Oct 5 is not documented consistently, so it gets a drill.

Work the calendar backwards from Oct 5:

Both outcomes need a handler before you know which one you’ll get. An error is easy: the lane fails and the runner alerts. A redirect shows up in what comes back: function_call steps from a 05-pinned request that name view_file, write_to_file or list_dir are 09 tools you didn’t ask for, and that lane runs only while the 09 suite is green. The runner’s refusal is the control; the API’s behaviour on the day is evidence.

Oct 5 is also a dated deprecation, so it belongs on the ledger that forced model routing continuity keeps for model-ID swaps; point that ledger entry at this suite as its proof. After any bump, the served-behaviour replay in the CLI upgrade canary checks what the lane was actually served. This suite checks that its guards still see it.

Step 6: Put a wall behind every guard the suite can’t prove

Hooks stay guardrails. The suite proves coverage and verdicts at test time; it can’t make a fail-open runtime fail closed or hook a tool the vendor never routes through hooks. Each such path gets a named wall and its own test:

For the Claude Code row, run the post-bump canary repo from restricted mode as fleet policy in the same gate as this suite; the cross-harness version is the managed-permissions override test. And remember what 2.1.275 fixed: the wall itself had been written as rules nothing matched. A permission rule is one more matcher, so it goes in the coverage assert too.

Where Antigravity agent hooks pass the suite and still guard nothing

The tool list came from the changelog. A tool in function_call steps but not in your list is invisible to every assert. Signal: a recorded tool name missing from the list.

The matcher moved; the field didn’t. The usual half-fix after a rename. Signal: the key-field assert fails, or the canary secret read logs allow from a guard that matched.

The guard matches too much. Claude Code 2.1.275 also fixed SubagentStop hooks with a specific matcher that fired for every stopping subagent whose agent type was empty. Signal: DRIFT lines from step 1. Over-broad guards get disabled by the people they annoy, which ends where a dead one does.

Green on Claude’s contract, open on Google’s runtime. Signal: the non-zero-exit replay reads allow on Antigravity for a guard someone ported from a Claude Code lane. The step 3 wrapper is the fix.

The suite ran once. Signal: the last green run is older than the last agent bump, or older than a day. Hosted agents and their docs change on their own calendar.

Guard coverage is fleet inventory, not a line in one hooks file

A fleet that runs Antigravity Agent, Claude Code and Codex lanes has three matcher dialects, three failure policies and three release trains. Reading one hooks.json tells you whether that file parses, not whether the fleet’s writes are guarded. Coverage is a join between what each lane runs today and what each guard matches, and only the layer that starts lanes, pins versions and holds the kill switch has both halves.

That’s where this suite belongs: in the multi-agent command center layer, beside the runner that refuses to start a lane whose pinned version has a red line. Chatbots suggest; agents act. A guard that stopped being asked is an agent acting with nobody watching.

FAQ

Do Antigravity agent hooks fail open?

Yes, on the Gemini API’s Antigravity Agent. Google’s hooks page says a crashed script, a non-2xx HTTP response, a timeout or unrecognised JSON is treated as allow. Only a deny decision from a working hook blocks the call. Hooks also skip custom function and mcp_server tools, so those need a gate elsewhere.

Will antigravity-preview-05-2026 error or redirect after October 5?

Google’s sources disagree. The deprecations page says a shut-down model’s endpoint is no longer available, which implies an error. Google’s gemini-skills migration table says 05-2026 requests redirect to 09-2026. Pin 09-2026 now, make your runner refuse 05 pins, and test both outcomes from a disposable lane.

Sources

• Gemini API changelog: 09-2026 release and tool table, Sep 17, 2026
• Gemini API deprecations: 05-2026 shutdown, Oct 5, 2026
• Gemini API agent hooks: matchers and failure handling, updated Sep 17, 2026
• Gemini API Antigravity agent: default tools
• gemini-skills migration reference: the redirect row
• gemini-skills PR #83: merged Sep 17, 2026
• Claude Code hooks reference: matcher rules, exit codes, timeouts
• Claude Code changelog: 2.1.191, 2.1.195, 2.1.210, 2.1.275
• Codex hooks docs: coverage table and deny shapes
• openai/codex issue #23411: Code Mode exec and PreToolUse, open

Until Sep 17, GitHub’s rule for who may start that run fit in one line: “every user with write access to a repository can trigger workflows.” GitHub Actions workflow execution protections, generally available since Sep 17, 2026, replace that default with an allowlist of actors and events you can target per workflow file. For a fleet of agents pushing as Apps, bots and tokens, it is the first native place to write down which CI runs each agent identity may start.

The move for Tuesday starts underneath the allowlist: strip workflow-edit and dispatch rights from agent tokens as two drilled steps, then write an agent trigger matrix whose every cell names its enforcing control. Encode its allow and deny cells as policies, drill each identity, time a kill switch, and list agent workflows on pull_request_target in public repositories before Nov 2.

Sep 17: GitHub Actions workflow execution protections reach GA

On Sep 17, 2026, GitHub’s changelog made workflow execution protections generally available for enterprises, organizations and repositories, after a public preview that opened Jun 18. The feature lets you “define an allowlist that controls who can trigger an Actions workflow and what events can start it.” In the post’s own words, “Actor rules cover the who, event rules cover the what, and actions evaluate both before a run.”

Per GitHub’s About Actions policies page, actor rules can name users, repository roles, GitHub Apps, Copilot and Dependabot, and event rules cover push, pull_request, pull_request_target, workflow_dispatch and others. GA added workflow-file targeting, so “a single repository can apply different policies to different workflows”, plus insights with an evaluate mode and a REST API. The how-to for controlling workflow execution marks Evaluate “GitHub Enterprise Cloud only”, layers policies from enterprise to organization to repository, and is blunt: “Non-allowed actors will not be able to run the specified workflows at all.”

The post also adds a default aimed at “Pwn Request” attacks, where fork code in a pull_request_target workflow can “poison your pipeline and exfiltrate secrets.” Public repositories with no event policy get a rule that disables pull_request_target, and “This default does not apply to private or internal repositories.” It starts in evaluate mode. Then: “On November 2, 2026, we’ll automatically enforce the default rule for affected repositories that were using the default pull_request_target policy before general availability.”

Screenshot: GitHub Changelog, “Workflow execution protections in GitHub Actions generally available” (Sep 17, 2026), captured Sep 21, 2026.

All of this lands on an approval patchwork keyed to which token opened the pull request. Copilot coding agent workflows “do not run until approved by a human with the Approve and run workflows button,” and since Mar 13 admins can switch that off per repository. PRs that a workflow creates or updates with GITHUB_TOKEN produce runs “in an approval-required state,” per GitHub’s trigger docs; since Jun 11 such bot PRs can run at all, once someone with write access approves. A PR created or updated by automation with a GitHub App installation token or a PAT runs its pull_request workflows “without the approval prompt described above.” Same agent, three answers; the token decides.

An agent’s push is a run request with the secrets attached

GitHub’s secure-use reference states the stakes: anyone with write access can read every secret configured in the repository. For a human collaborator, that is a trust decision someone made. For an agent, it is a side effect of the push access it needed.

Editing a workflow file is the obvious attack, and Step 0 drills it. The common path needs no workflow edit. An agent that changes a test script, a package.json script or a Makefile has changed what an existing, secret-bearing push workflow executes, and that workflow runs on the push.

Merge-time controls such as the overnight merge gates for agent PRs and the CODEOWNERS and secret-scanning gates in agentic CI/CD judge the change after CI has already run it. So does GitHub’s Sep 9 rule, in public preview, that blocks merging pull requests with unresolved secret-scanning alerts.

The fix-loop guards scope the agent’s own token, and the headless trust tier decides who may trigger an agent run. This runbook covers the inverse: which CI runs an agent identity can start, and what they reach. It assumes one GitHub App per lane, as in the service-principal playbook for agent identity. With one shared identity, every row of the matrix collapses into one.

Step 0: Remove edit rights and dispatch rights as two separate drills

Workflow edits and dispatch are separate permissions on Apps and fine-grained tokens, so remove and drill them one at a time.

Edit rights. Take the workflows permission off every agent GitHub App and fine-grained token, and the workflow scope off every classic PAT an agent holds. GitHub’s permission table for Apps files the writes that touch workflow files under “Workflows”: PUT and DELETE on contents, git ref writes and release writes. The drill: from the agent’s runtime, with its production token, push a branch that changes a file under .github/workflows/. The push must be rejected.

Dispatch rights. Take Actions write off every agent App and fine-grained token. The dispatch endpoint, POST /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches, sits under repository “Actions” write for Apps and fine-grained tokens alike. The drill: gh workflow run with the agent’s token must fail. Classic PATs are the exception. The dispatch reference says “OAuth tokens and personal access tokens (classic) need the repo scope to use this endpoint,” so any classic PAT holding repo can dispatch any workflow that declares workflow_dispatch. Move PAT agents to an App or a fine-grained token, or deny them workflow_dispatch by policy in Step 3.

Admin rights. The Actions policies API needs Administration write, even for a GET. An agent token that can read your policies can also rewrite them. No lane holds one.

# edit-dispatch-drill.sh: illustrative. Run inside the agent lane's runtime with the
# token that lane receives in production, against a scratch repo nothing depends on.
# The scratch repo holds one workflow that declares workflow_dispatch; git must
# authenticate with the same token (credential helper or remote URL).
set -u
REPO="your-org/trigger-drill"
WF="drill-dispatch.yml"
export GH_TOKEN="$AGENT_TOKEN"

# 1. Edit: a push that touches .github/workflows/ must be rejected.
git switch -c "drill/wf-edit-$(date +%s)"
echo "# drill $(date -u +%FT%TZ)" >> ".github/workflows/$WF"
git commit -qam "drill: workflow edit from agent identity"
git push -q origin HEAD && echo "FAIL edit: push accepted" || echo "PASS edit: push rejected"

# 2. Dispatch: creating a workflow_dispatch event must fail.
gh workflow run "$WF" --repo "$REPO" && echo "FAIL dispatch: run created" || echo "PASS dispatch refused"

# 3. Admin: the policies API needs Administration write; an agent token must not read it.
gh api "repos/$REPO/actions/policies" > /dev/null && echo "FAIL admin: policies readable" || echo "PASS admin refused"

Run it for every lane now and after every token rotation, and keep the exact error each refused call returns.

Step 1: Write the agent trigger matrix, and name the control in every cell

The matrix is a checked-in file the platform team owns, reviewed like any change to .github/workflows/.

Rows are the identities agents push or dispatch as. Five kinds cover most fleets:

• Copilot, which actor rules name directly.
• One GitHub App per lane, so a review agent and a dependency agent get different cells.
• PAT agents. The docs don’t say how a PAT-authenticated push is attributed for actor rules, so test whether a policy sees the agent or the token’s human owner.
• github-actions[bot], for pull requests your own workflows open.
• Dependabot. GitHub’s own features are exempt, but bot identities such as dependabot[bot] must be added as allowed actors when a custom workflow needs them.

Columns are workflows grouped by reach, crossed with the event: no secrets, repository secrets, environment secrets, OIDC deploy roles, each split by push, pull_request, pull_request_target and workflow_dispatch.

Every cell gets a verdict (allow, approval-required or deny) and its enforcing control. Execution protections only allow or block; they have no ask. So an approval-required cell means the run may start and the job holding the secret runs in an environment with required reviewers, because “A workflow job cannot access environment secrets until approval is granted by a reviewer.” An approval cell that names no environment is an allow.

The approval prompt is real but narrow. It holds Copilot coding agent runs until an admin turns it off, and runs from GITHUB_TOKEN-created PRs, but never a PR that automation opened with an App token or PAT. Never make it the only control on a secret-bearing column.

EP is an execution-protection policy, and workflow_dispatch is deny for every agent row. The file looks something like this:

# ci/agent-trigger-matrix.yaml: illustrative shape. Owned by the platform team;
# reviewed like .github/workflows/. EP = execution-protection policy.
identities:
  copilot:          { kind: copilot }
  review-agent:     { kind: app, app: acme-review-agent }   # one App per lane
  deps-agent:       { kind: app, app: acme-deps-agent }
  legacy-pat-agent: { kind: pat, owner: a-human-login, attribution: untested }
  actions-bot:      { kind: bot, login: "github-actions[bot]" }
  dependabot:       { kind: bot, login: "dependabot[bot]" }
workflow_groups:
  no-secrets:   [.github/workflows/lint.yml, .github/workflows/unit.yml]
  repo-secrets: [.github/workflows/integration.yml]
  env-secrets:  [.github/workflows/release.yml]    # release job declares environment: release
  oidc-deploy:  [.github/workflows/deploy.yml]     # deploy job declares environment: production
cells:
  - { who: [copilot, review-agent, deps-agent, dependabot], group: no-secrets, event: [push, pull_request], verdict: allow, control: EP }
  - { who: [copilot, review-agent, deps-agent], group: env-secrets, event: [push], verdict: approval, control: "EP allow + environment release with required reviewers" }
  - { who: agents, group: [repo-secrets, oidc-deploy], event: all, verdict: deny, control: EP }
  - { who: agents, group: all, event: [workflow_dispatch], verdict: deny, control: "EP + Step 0 token scopes" }
  - { who: legacy-pat-agent, group: all, event: all, verdict: deny, control: "replace with an App before any policy relies on it" }

Step 2: Move secrets out of reach of runs an agent can start

Two gates in series. The allowlist decides whether the run starts; the environment decides whether a job gets its secrets.

Repository secrets sit between the two gates, open to any job in a run that started, which makes the repo-secrets column of the matrix the one that matters most.

For each workflow an agent identity can start, list the secrets it reads. Delete what it doesn’t need. Move what it needs only for a release, deploy or publish step into an environment with required reviewers, as a separate job that declares that environment.

Set the default GITHUB_TOKEN to read-only, as the secure-use reference advises, and grant write per job. Treat an OIDC deploy role the same way: assume it only inside a reviewed environment, never in the job that runs the agent’s test script.

Then re-sort the columns. A workflow that no longer reads repository secrets moves to the no-secrets column and can stay open to agent pushes. Most of this runbook’s risk reduction happens here, before a single policy exists.

Step 3: Encode the allow and deny cells as GitHub Actions workflow execution protections

Only the allow and deny cells become policies. Approval cells are the environment settings from Step 2.

The REST reference for Actions policies gives the fields: name; enforcement, one of disabled, active or evaluate; rules, holding restrict_actions_actors and restrict_action_events; and conditions, using repository_name, repository_id, repository_property or workflow_path. Actor types are User, Bot, Team and App. Three rules keep the translation honest.

Target every policy by workflow file. The reference says why: “Omitting workflow_path targets all workflows without storing an explicit condition.”

Split before you deny dispatch. Per the how-to, “If you also restrict events, these users will only be able to trigger workflows with the allowed events.” A policy’s allowed actors get only its allowed events. If one workflow file takes agent pushes and human dispatches, allowing both events lets agents dispatch, and allowing only push takes dispatch away from the humans too. Split it into a push workflow agents may start and a dispatch workflow only humans may start, then deny workflow_dispatch to agent identities on the second.

Shadow it where you can. Run a week in evaluate mode if you have GitHub Enterprise Cloud; elsewhere, put one repository in active and run the Step 4 drill the same day. Whether non-enterprise organizations can view policy insights is disputed, so check your own org first.

Apply the policy files from a human-owned pipeline that holds the Administration-write credential, never from a lane.

# policies/agent-trigger.yaml: illustrative intent file. A human-owned pipeline
# with Administration write translates each entry into the REST fields
# (name, enforcement, rules, conditions) and applies it.
- name: release-deploy-humans-only
  scope: organization
  enforcement: evaluate          # Enterprise Cloud only; elsewhere one repo in active first
  conditions:
    workflow_path: [.github/workflows/release-dispatch.yml, .github/workflows/deploy.yml]
  allowed_actors: [team:release-managers]
  allowed_events: [push, workflow_dispatch]
- name: tests-agents-may-start
  scope: organization
  enforcement: evaluate
  conditions:
    workflow_path: [.github/workflows/lint.yml, .github/workflows/unit.yml]
  allowed_actors: [team:engineering, app:acme-review-agent, app:acme-deps-agent, copilot, "bot:dependabot[bot]"]
  allowed_events: [push, pull_request]
- name: kill-switch-agents-off-sensitive
  scope: organization
  enforcement: disabled          # a human flips this to active (Step 5)
  conditions:
    repository_property: { sensitivity: high }
  allowed_actors: [team:engineering]
  allowed_events: [push, pull_request, workflow_dispatch]

Step 4: Drill from every agent identity, and write down what you see

A policy you haven’t drilled is a guess. From each agent identity, try each denied cell: push to a branch that triggers a denied workflow, open a PR, dispatch. Add a positive control, a human dispatch that must still run, so you notice when you have denied too much.

Expect a failed run with an error. GitHub documents the text only for event blocks: “Event ‘workflow_dispatch’ is not allowed to trigger Actions workflows. Workflow file: ‘.github/workflows/0-welcome.yml’.” The docs show no text for an actor-rule block, so record the exact error each run gives you rather than matching on a string.

Screenshot: GitHub Docs, “About Actions policies” (undated), captured Sep 21, 2026.

Two tests cover what the docs don’t say. The first finds which identity counts as the actor on a pull request synchronize push, both when an agent pushes to a human’s PR and the reverse. The second finds whether a PAT agent’s run is attributed to the agent or to the token’s owner. Let both answers rewrite the PAT and bot rows.

Re-run the log after every policy change, token rotation or new lane. I’d keep it beside the matrix, so a reviewer sees a cell change and its drill result together.

Step 5: Time an org-level kill switch for agent actors

Write one more organization policy before you need it. It targets every sensitive workflow, by workflow_path or by a repository_property such as a sensitivity tag, allows human actors only, and sits in disabled (the last entry in the Step 3 file). When a lane misbehaves, a person flips it to active and every agent identity drops off those workflows.

Don’t assume the switch is instant. Measure it: minutes from the decision to the first blocked run from an agent identity. In the same drill, prove the switch blocks an agent that another policy allows.

Policies are evaluated before a run starts, so the switch stops new runs, and runs already in flight need a separate cancel. Rehearse it each quarter with nothing at stake, and keep the credential that flips it with a human.

Step 6: Before Nov 2, list agent workflows on pull_request_target in public repos

Every date is from GitHub’s changelog. Nov 2 is scheduled, not yet in force, and covers affected public repositories only.

The default rule reaches only public repositories that were on the default pull_request_target policy, and it blocks only one event, so the inventory is small enough to finish this week. GitHub’s secure-use reference already warns that “The pull_request_target and workflow_run workflow triggers, when used with the checkout of an untrusted pull request, expose the repository to security compromises.” Agent review and triage jobs are prime candidates.

For each public repository:

1. List the workflows triggered by pull_request_target (script below).
2. Mark the ones that run an agent: review bots, triage lanes, auto-fix jobs.
3. Check whether the repository already has an event policy. If it does, the default rule doesn’t apply, and your policy decides.
4. Decide per workflow: let the rule block it and move the agent to pull_request with no secrets, or write an explicit event policy that allows pull_request_target for that one workflow file and review what it checks out.
5. Where insights are visible to you, compare your list with what evaluate mode says would fail.

# prt-inventory.sh: illustrative. Lists public repos whose workflow files mention
# pull_request_target, for a human to sort into agent and non-agent workflows.
ORG="your-org"
gh repo list "$ORG" --visibility public --limit 1000 --json name --jq '.[].name' |
while read -r repo; do
  gh api "repos/$ORG/$repo/contents/.github/workflows" --jq '.[].path' 2> /dev/null |
  while read -r path; do
    gh api "repos/$ORG/$repo/contents/$path" --jq '.content' | base64 -d |
      grep -q 'pull_request_target' && echo "$repo  $path"
  done
done

Where GitHub Actions workflow execution protections leak, and the signal for each

The secret-bearing push workflow nobody moved. Signal: an agent commit that changes package.json scripts, a Makefile or a test helper on a branch whose push workflow reads repository secrets. Fix: Step 2 for that workflow, today.

A PAT agent wearing its owner’s identity. Signal: the Step 4 drill from a PAT agent succeeds where the same cell blocks the lane App. Fix: move the agent to an App; if the policy sees the human, no actor rule can tell the two apart.

The untargeted policy. Signal: human runs blocked on workflows you never meant to touch. Cause: a policy with no workflow_path, which targets everything.

The new workflow file. Signal: a workflow file added since the last policy review that no targeted policy names. Fix: a daily diff of workflow files against policy targets, the same coverage assert the guard contract suite runs against hook matchers.

A gate that isn’t there. Execution protections are a guardrail on run starts, not a complete boundary. A policy left in disabled or evaluate, a workflow no targeted policy names, GitHub’s exempt own features and a run that started before the switch flipped all get through. The wall behind the allowlist is Step 0’s tokens that can’t edit or dispatch and Step 2’s secrets that wait for a reviewer. Keep both even when the policies look complete.

Trigger rights belong in the fleet’s identity inventory

The matrix is an inventory record first and a GitHub setting second. Every agent identity should appear in it the day it is created, next to its token scopes and publish rights; the stage-only token classes for publish lanes are the same exercise for npm. A lane that reads untrusted text and can start a secret-bearing workflow holds all three legs of the Rule of Two, and the matrix is where you will see it first.

That view belongs in the command center that runs the fleet, beside the kill switch and the drill log, not on a settings page three clicks into one organization. GitHub now supplies a native allow and block. Deciding which identity gets which run, and proving it still holds after next month’s new lane, stays your job.

FAQ

Can a coding agent with write access trigger GitHub Actions workflows?

Often, yes. Until Sep 17, GitHub’s rule was that every user with write access could trigger workflows, and only some agent tokens hit an approval prompt. Workflow execution protections now let you allowlist the actors and events that may start each workflow file, so you decide which runs each agent identity can start.

Does GitHub’s default pull_request_target rule apply to private repositories?

No. GitHub says the default rule does not apply to private or internal repositories. Automatic enforcement on Nov 2 reaches only public repositories with no event policy that were on the default pull_request_target policy before general availability. Where a public repository has an event policy, the default rule doesn’t apply and your policy decides.

Can a classic personal access token dispatch GitHub Actions workflows?

Yes. GitHub’s dispatch reference says classic personal access tokens need the repo scope, so any classic PAT holding repo can dispatch any workflow that declares workflow_dispatch. There is no separate dispatch right to remove. Move PAT agents to a GitHub App or fine-grained token, or deny them workflow_dispatch with an execution-protection policy.

Sources

• GitHub Changelog: Workflow execution protections in GitHub Actions generally available (Sep 17, 2026)
• GitHub Changelog: Optionally skip approval for Copilot coding agent Actions workflows (Mar 13, 2026)
• GitHub Docs: About Actions policies (rule types, event-block error)
• GitHub Docs: Controlling who can execute GitHub Actions workflows (evaluate mode, layering)
• GitHub Docs: Secure use reference (secrets, pull_request_target, environments)
• GitHub Docs: Triggering a workflow (approval prompt by token type)
• GitHub REST API: Actions policies (policy fields)
• GitHub REST API: Create a workflow dispatch event (classic PAT repo scope)
• GitHub REST API: Permissions required for GitHub Apps (Actions, Workflows)
• GitHub REST API: Permissions required for fine-grained personal access tokens (Actions, Administration)

AI vendor data routing is invisible from where your runner sits. Your egress log shows the host the runner called. It can’t show whether that host answered, forwarded the request to another provider, or pushed it through someone else’s account and kept a copy. You can see the first hop. Everything after it is a contract or a claim.

This piece turns that gap into a register. By Tuesday every vendor lane in your fleet has one row with five columns: the contracting entity, its stated sub-processors, its onward-routing and resale terms, whether a response names the model that answered, and what you verified versus what you were told. Each lane then carries a data-class cap set by what its last hop can be verified to be, and your runner refuses to send a restricted repo to a lane whose last hop is only a claim.

Chatbots suggest; agents act. A chat user pastes one paragraph. An agent lane ships whatever it can reach, tool output and environment included, on every turn, with nobody reading along, so where its prompts end up is a property of the lane, not of any one conversation.

Sep 10: Anthropic’s threat report alleges relays customers never saw

Anthropic’s threat-intelligence report, “Detecting and countering misuse of AI”, covers December 2025 to August 2026. The page says only “September 2026”; TechCrunch and CNBC date its release to Thursday, Sep 10. Where most of the report hedges, the distillation section doesn’t: Anthropic says it attributed those campaigns “with high confidence to specific PRC-based labs”.

The Moonshot case, labelled GTG-16002, is the one a register cares about. Anthropic says Moonshot “silently forwarded customer requests to Claude, instead of processing them using Kimi”, and puts a number on one window: “In one instance, over a ten-day period, Moonshot relayed almost 300,000 customer requests to Anthropic, the vast majority of which were routed to Opus.” By Anthropic’s account the traffic ran through a proxy network of 5,380 fraudulent accounts, most of which appeared to be in Singapore and Japan. Anthropic also says Moonshot “captured and saved at least a portion of these exchanges”, and that the rerouted queries included sensitive information about Moonshot’s customers. And it names what it doesn’t know: “We do not know if Moonshot notified their customers that their requests were being rerouted to Anthropic and exposed to a third party.”

Screenshot: Anthropic, “Countering misuse of AI: September 2026” (September 2026), captured Sep 21, 2026.

Moonshot is not the only case in the report, and the others sit closer to how fleets buy access. Anthropic says DeepSeek silently relayed exchanges to Claude, including requests from users working in coding harnesses such as Claude Code, the Claude Agent SDK and OpenCode. It says Xiaomi replayed user sessions, many of them routed through third-party model routing services; that SenseTime bought transcripts from intermediaries that “logged the transcripts and sold them”; and that MiniMax built a proxy network through a shell company. The general line reads like a note to operators: “Many of these exchanges were relayed from users of third-party model routing services commonly used by users in the United States and Europe.”

The totals need care. TechCrunch counts “nearly 200 million exchanges” across five campaigns; Anthropic’s page gives no grand total, and its per-lab scale lines add up to about 190 million. CNBC reported that Alibaba, Moonshot, DeepSeek, Xiaomi and Anthropic “did not immediately respond” to its requests for comment, and no Moonshot statement had appeared by Sep 21.

Read the gaps as carefully as the claims. For the Moonshot case the report names no product surface (not Kimi Code, not the Kimi CLI), doesn’t say how long anything was kept, and doesn’t say whether API or enterprise customers were affected. Nothing in it says a particular lane leaked, and nothing here claims one did. Every allegation above is Anthropic’s. It is also Anthropic’s second pass: its February disclosure named three of the same labs.

Step 1: Map AI vendor data routing with one five-column row per lane

A lane, for this register, is one path a prompt can take: harness, endpoint, account and plan. The same vendor on a consumer plan and on a signed API agreement is two rows, because the terms are two different documents. Routers, gateways, resellers and BYOK proxies are rows too. Any hop you configure gets one, including the one a developer added last week to save money.

Each column maps to a line in the report. The contracting entity matters because, by Anthropic’s account, MiniMax ran its proxy service through a shell company; the brand on the landing page and the entity on the invoice are separate facts. Sub-processors carry a date because the list is a snapshot. Onward routing is the Moonshot question. Resale and logging is the SenseTime question: Anthropic says intermediaries between users and the model logged the transcripts that were later sold.

Column 3 has a second half people skip: whose account the upstream call runs on. Anthropic’s report notes that “Stolen keys and accounts have resale value in established markets”, and it describes Moonshot’s relay as running on fraudulent accounts. A reseller that can’t say it holds its own agreement with each upstream is a hop whose access can vanish overnight and whose logs belong to a stranger.

Screenshot: Anthropic, “Countering misuse of AI: September 2026” (September 2026), captured Sep 21, 2026.

Two neighbouring controls stay out of this register. The keys a lane holds belong with stage-only tokens for agents, and spend spikes on those keys belong with cost anomaly alerts. If you keep the trust ledger from the Chinese coding CLIs review, with its jurisdiction, terms and paths, add these columns to it rather than starting a second file. Trust, by usage path classifies workloads by vendor; this register classifies them by where the vendor sends them. How long any hop keeps your prompt is a retention question with its own piece.

Step 2: Grade every cell verified, contracted, attested or unknown

The register is only as honest as its grades, so define them before anyone fills a cell.

Grade honestly and an uncomfortable pattern appears. From the client side you can verify exactly one hop, the first. The egress log proves the host, and the invoice proves the counterparty. Past the vendor’s front door the best available grade is contracted. The only lanes whose last hop is verified by construction are those where the first hop is the last one: open weights you run on hardware you control, with that host’s egress denied, or a gateway you operate in front of such a model.

That isn’t an argument against hosted vendors. Contracts are how companies extend trust to each other, and a lane that tops out at contracted is fine for most code. What the grades stop is quiet promotion: a trust page read as a promise, a sub-processor list read as complete, a model name read as proof. A questionnaire answer is attested however formal it looks. A contracted cell with no link to a signed document gets downgraded on sight.

You hold the evidence for the first hop. Past it, you are handed evidence, and the cap follows the weakest grade.

Step 3: Ask the onward-routing question in writing

Anthropic’s numbers are why column 3 exists. The scale lines count the distillation exchanges Anthropic attributes to each lab. The tiles are the Moonshot relay, the part that carried Moonshot’s own customers’ requests, and by Anthropic’s account it happened silently.

Anthropic’s allegations, charted from its own page on a log scale. The per-lab lines sum to about 190M; TechCrunch rounds the total to nearly 200M.

Send every vendor and intermediary in the register the same six questions, and ask for answers in writing from someone who can sign for the company.

1. Is every request answered by the model named in our agreement and in the response? If not, which other models answer, and when?
2. Is any request, in whole or in part, sent to another model provider? On whose account?
3. Do you log prompts or completions? Who can read those logs, and are they ever sold, shared or used for training?
4. Which sub-processors receive prompt content? Send the list with its date.
5. Do you resell access to another provider’s models? If so, do you hold your own agreement with that provider?
6. Will you notify us before any of the above changes, and how far in advance?

File each answer with its date and signer. A written answer moves a cell from unknown to attested; only a signed term moves it to contracted. A vendor that declines question 2 has still answered it for the register: the cell stays unknown.

Routers get the same questions, and harder. A hosted router is its own row, and its model pool is column 3 by definition. Routers you can’t see inside scores their visibility; carry that grade into column 4 here instead of redoing the work.

Step 4: Probe whether a response names the model, then grade the name as attested

Column 4 is the only one you can test from the client. Run a fixed probe from the lane’s own runtime, with its own endpoint and credential, and keep every result.

# probe-model-field.sh (illustrative shape; adapt the request to the lane's API)
# Run inside the lane's runtime on a schedule and after every CLI upgrade.
for i in $(seq 1 20); do
  curl -s "$LANE_BASE_URL/chat/completions" \
    -H "Authorization: Bearer $LANE_KEY" -H "Content-Type: application/json" \
    -d "{\"model\":\"$LANE_MODEL\",\"messages\":[{\"role\":\"user\",\"content\":\"Reply with ok.\"}],\"max_tokens\":5}" \
  | jq -c --arg lane "$LANE_ID" --arg want "$LANE_MODEL" \
      '{lane:$lane, requested:$want, reported:(.model // "absent"), ts:(now|todate)}'
done >> "register/probes/$LANE_ID.jsonl"

Grade the result on three levels: exported (a model ID per call that your runner stores), displayed (a person can see it on screen) and not exposed. Vendors differ. GitHub’s docs say “You can see which model was used for each Copilot response.” Cursor’s router shows the routed model in its Balance and Intelligence modes only if an admin turns on the Underlying model setting, which is hidden by default. Sakana names models that are not in Fugu Ultra v2’s pool, which is not the same as naming the one that answered.

Then grade every name you get as attested. The model field is written by the vendor’s server, and the Moonshot allegation is exactly a case where, by Anthropic’s account, users saw one company’s product and received another company’s model. A name can’t verify the hop that wrote it. The probe still earns its place as a tripwire: a model you didn’t request, or a field that goes from a value to absent, is a step 6 trigger.

Step 5: Cap each lane’s data class and enforce the cap at dispatch

Classify repos into four classes, and write the definitions where the runner can read them.

• Public: open-source repos, published docs.
• Low: internal but harmless if published, such as build tooling and fixtures with no customer data.
• Confidential: proprietary product code, internal tickets, designs.
• Restricted: customer or regulated data, security-sensitive code, anything with live credentials in reach. Anthropic’s own examples from the relay include an engineer who, in its framing, revealed internal code and live credentials.

Then compute each lane’s last-hop grade as the weakest grade across columns 1 to 3. Column 4 stays out of the arithmetic, because for a hosted lane it can never rise above attested; it works as a trigger instead. The grade sets the cap. This mapping is a starting policy, not a standard, so tighten it to your own risk appetite.

Read the bottom two rows together: a lane whose last hop you can neither observe nor enforce gets public or low-class repos only.

# register/lanes.yaml (illustrative shape; the runner reads it, lanes never do)
- lane: review-bot-vendor-a
  endpoint: api.vendor-a.example
  plan: signed-api-agreement
  contracting_entity: {name: "Vendor A Ltd", parent: "Vendor A Group", grade: verified}
  sub_processors:     {source: "DPA annex, 2026-07", grade: contracted}
  onward_routing:     {source: "MSA s.9, no onward routing or resale", grade: contracted}
  model_identity:     {level: exported, grade: attested}   # vendor-written; a trigger, not an input
  last_hop_grade: contracted                               # weakest of columns 1-3
  data_class_cap: confidential
  open_triggers: []
  reviewed: 2026-09-21

The dispatch gate runs in the runner before the harness starts, and every path that isn’t a clean yes is a refusal.

# last_hop_gate.py (illustrative shape): exit 0 lets the lane start; anything else refuses
import sys, yaml

ORDER = ["public", "low", "confidential", "restricted"]
CAP = {"verified": "restricted", "contracted": "confidential", "attested": "low",
       "unknown": "public", "contradicted": "public"}

try:
    lane_id, repo = sys.argv[1], sys.argv[2]
    lanes = {l["lane"]: l for l in yaml.safe_load(open("register/lanes.yaml"))}
    lane = lanes[lane_id]                                   # unregistered lane = KeyError = refuse
    classes = yaml.safe_load(open("policy/repo-classes.yaml"))
    repo_class = classes.get(repo, "restricted")            # unclassified repo = restricted
    grade = "unknown" if lane.get("open_triggers") else lane.get("last_hop_grade", "unknown")
    cap = CAP.get(grade, "public")
    if ORDER.index(repo_class) > ORDER.index(cap):
        sys.exit(f"refuse {lane_id} -> {repo}: {repo_class} exceeds cap {cap} ({grade})")
except Exception as e:
    sys.exit(f"refuse: last-hop gate error {e!r}")          # fail closed

Be plain about what the gate can’t do. It sees lanes the runner starts, and a developer who launches the harness by hand with the lane’s endpoint skips it. So the gate isn’t the wall. The wall is the lane’s own access: its checkout credential can read only repos at or below its cap, and its egress allowlist reaches only the endpoint in its row. A hand-launched session with the lane’s credential still can’t clone a restricted repo or reach an unregistered host.

Two siblings plug into the same cap. A fallback route inherits every class the primary might carry, so the fail-mode playbook clears one default route for every data class it may see. And the Rule of Two lane split scores what a lane can reach on its sensitive-data leg; the last-hop cap decides where that data may go.

Step 6: Re-grade on triggers, and treat an allegation as a trigger, not a verdict

A register filled once is a snapshot with a confident filename. Wire these triggers to a re-grade, and record who re-graded and when.

The allegation row needs the most discipline. A credible report that names a vendor is evidence about that vendor’s last hop, and ignoring it is a choice you would have to defend later. It is not proof that your lane leaked, and the register shouldn’t say so. Mark the relevant cells contradicted, let the lane keep running on public repos, send the six questions, and re-grade when the answer arrives: a written reply returns the cell to attested, a signed amendment to contracted. Date every step. If anyone asks in six months what you did the week the report landed, the register answers.

Where AI vendor data routing slips past the register, and the signal for each

The unregistered router. A lane gets pointed at a cheaper gateway or BYOK proxy. Signal: an egress host with no register row.

The plan swap. Same vendor, but the lane now runs on a consumer or team plan whose terms differ from the row. Signal: the invoice counterparty or account type no longer matches column 1.

Attested, filed as contracted. A trust-page promise lands in the contracted column. Signal: a contracted cell with no link to a signed document.

Name drift. The model field changes, or disappears. Signal: the probe log shows a value you didn’t request, or absent, with no open trigger.

Cap rot. A repo moves up a class, but lanes keep getting dispatched to it on the old answer. Signal: a repo-class change newer than the lane’s last gate record.

The side door. A lane’s session is exported or imported into another tool whose provider has no row. Signal: session-import events in the audit log for a lane capped below the source repo’s class.

The last-hop register belongs to the layer that starts lanes

None of this lives in a prompt, and none of it can. A model can’t tell you where its own request went, and a vendor’s model field is the vendor talking. The register, the grades, the repo classes, the gate and the probe log sit in the layer that starts lanes, which is also the only place that sees every vendor at once. That layer is what a multi-agent command center is once you strip the dashboard off: one inventory of lanes that knows what each may carry, and why.

The register won’t make any vendor honest. It makes your own exposure a number you chose, written down with the evidence beside it, and it lets you tighten that number the morning a report like this one lands, without waiting for anyone to answer.

FAQ

Can an AI vendor send my prompts to another model provider?

It depends on the terms, and from the client side you can’t see it happen. Your egress log shows only the first host. Anthropic alleges that Moonshot and DeepSeek relayed customer requests to Claude. Ask each vendor in writing, prefer a signed clause, and cap what each lane may carry.

What is a last-hop register for AI agents?

A per-lane record of where a prompt can end up: the contracting entity, stated sub-processors, onward-routing and resale terms, and whether responses name the answering model, each graded verified, contracted, attested or unknown. The weakest grade sets the highest data class the runner will send to that lane.

Sources

• Anthropic, Detecting and countering misuse of AI (September 2026) — GTG-16002 and the other relay allegations; per-lab scale lines
• TechCrunch, Anthropic details distillation campaigns from Alibaba, Moonshot AI, and DeepSeek — Sep 10, 2026; the total
• CNBC on the Anthropic report — Sep 10, 2026; requests for comment
• GitHub Docs, Auto model selection — model shown per response
• Cursor Docs, Cursor Router — Underlying model setting
• Sakana AI, Fugu Max release — Sep 11, 2026; Fugu Ultra v2 pool exclusions

The move is a differential run, with Claude Code bare mode (claude --bare -p) as the launch line it should end on. Run the same unattended job from a clean config home and a used one, record every skill, plugin, instruction file and memory file each run read or wrote, and fail the lane on anything its manifest didn’t declare. Bare mode skips most discovery; the differential proves it did and catches what still gets through.

A chatbot that picks up a stray instruction gives a stranger answer. A headless lane that picks one up opens a pull request or skips a check, and the first person to notice is whoever reviews the diff. You can’t call a run reproducible until you know what its inputs were.

Three new state sources reached unattended lanes on Sep 16–18

Three launches in three days added state a headless run picks up with no config edit.

Sep 16: Grok Build memory. Grok Build now carries conventions, decisions and project facts between sessions. “Capture runs on every completed turn and does not interrupt the session.” Notes are markdown files in a per-project scope plus a global scope that applies everywhere, and memory applies to new sessions (Grok Build memory). The page documents no off switch.

Sep 17: Claude Code 2.1.275. The changelog entry reads “Added syncing of the skills and plugins enabled on your claude.ai account to terminal sessions signed in with it”, with opt-outs syncClaudeAiSkills: false and syncClaudeAiPlugins: false (Claude Code changelog). The settings reference adds what matters for lanes: sync runs “interactive or non-interactive”, skills land in ~/.claude/skills/synced/, plugins load from ~/.claude/plugins/synced/ as <name>@synced, and “A repository can’t turn it off for you” (Claude Code settings reference).

Sep 18: Claude Code 2.1.277. “Added AGENTS.md support: in a project with no CLAUDE.md, Claude Code reads AGENTS.md instead”, changeable under “Project instructions” in /config, with a caveat in parentheses: “(not yet on Bedrock, Vertex or Foundry)”. The same repo now loads different instructions depending on which provider sits behind the lane.

Screenshot: Claude Code Docs, “Claude Code changelog” (2.1.277 entry, Sep 18, 2026), captured Sep 21, 2026.

Sync and the AGENTS.md fallback shipped a day apart, and the AGENTS.md read is off in more places than the three providers the changelog names. Step 2 turns that into test design.

An instruction file is context, and a lane acts on context

Claude Code’s memory docs say it plainly about CLAUDE.md and AGENTS.md: “Claude treats them as context, not enforced configuration” (Claude Code memory docs). A skill is instructions; a memory note is instructions an earlier session wrote. None of it passes a permission rule on its way into the prompt, and all of it shapes what the lane does next.

The headless agent trust tier piece already pins the unattended flag line and hashes instruction files per tier; keep doing that. It predates account sync and per-turn memory, and a hash only covers files you knew to hash. AGENTS.md rot records what a repo’s instruction files say, and memory that burns quota prices what memory costs. This test does the part none of the three covers: it excludes state and proves the exclusion held.

Step 1: Write down what the lane may read and write

Start with a state manifest per lane. It names every input the runner passes explicitly and every place the lane may write, and it leaves the rest empty on purpose.

# lane-state.yaml (illustrative shape): read by the runner, never shown to the agent
lane: nightly-deps
harness: claude-code
cli_version: 2.1.278
launch: claude --bare -p
auth: api-key                  # ANTHROPIC_API_KEY or an apiKeyHelper; no subscription login
provider_path: anthropic-api   # AGENTS.md reading and claude.ai sync depend on it
env_allow: [ANTHROPIC_API_KEY, CI, LANE_ID]
reads:
  instructions: [lane/nightly-deps.md]   # --append-system-prompt-file
  settings: [lane/settings.json]         # --settings
  mcp_servers: [issues-readonly]         # --mcp-config
  skills: []
  plugins: []
  memory: none
writes:
  paths: [repo working tree, lane/out/]
  memory: none

Three rules keep it honest. Every entry is passed by flag or mounted by the runner; nothing is inherited from a home directory. The empty lists are the point, because the test fails on anything that appears in them. And the environment is an allowlist, because one variable can undo bare mode.

Step 2: Build a clean home and a used home, and hold everything else fixed

The two homes differ only in accumulated state. Build the clean one fresh for every run, in a new container or a throwaway user account. The used one is a long-lived runner’s home, signed in the way production runners are, with months of sessions behind it.

The fixture repo carries an AGENTS.md and no CLAUDE.md, because that is the combination 2.1.277 changed.

Two variables flip Claude Code’s AGENTS.md reading and claude.ai sync together. The first is feature-flag fetching, which Claude Code skips when DISABLE_TELEMETRY, DO_NOT_TRACK, DISABLE_GROWTHBOOK or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC is set, on third-party providers including Amazon Bedrock and Claude Platform on AWS, and in a Claude apps gateway session. Without the flags it loads CLAUDE.md files only and doesn’t sync (Claude Code environment variables). Copy the production environment and provider path into both homes, or you are testing a lane you don’t run.

The second is the first session. After an install, or an upgrade that adds a feature, a flag-gated feature can be missing until the flags arrive; the memory docs put it as “Claude reads AGENTS.md from your next session on”. A clean home is a first session by construction, so run it twice and judge the second run.

One more trap: a fresh worktree is not a fresh home. Claude Code derives the auto-memory directory from the git repository, so “all worktrees and subdirectories within the same repo share one auto memory directory”. A lane handed a new worktree on a used runner inherits every note earlier sessions wrote for that repo.

Step 3: Record every read and write three ways

One source of evidence isn’t enough; the harness doesn’t report everything it loads.

1. The harness’s own inventory. Claude Code’s headless system/init event reports plugins, plugin_errors, mcp_servers and mcp_server_errors, and the docs note that a CI gate can fail on a non-empty array (Claude Code headless docs). Compare those arrays with the manifest rather than with emptiness, so a declared MCP server passes and an undeclared one fails.
2. A filesystem diff for writes. Hash every file in the home before and after the run. Synced skill and plugin downloads, auto-memory notes and Grok Build notes all show up as new or changed files.
3. An OS-level read trace. This is the only reliable way to see an AGENTS.md read. The memory docs say an AGENTS.md read directly is “Not listed” in /memory or /context, and InstructionsLoaded hooks “Don’t fire” for it. An audit built on the harness’s own context view misses exactly the file 2.1.277 added.

# record-run.sh (illustrative): one run in one home; repeat for the clean home (twice) and the used home
find "$HOME" -type f -exec sha256sum {} + | sort -k2 > before.txt
strace -f -e trace=open,openat -o reads.log \
  claude --bare -p "$(cat lane/task.md)" \
    --append-system-prompt-file lane/nightly-deps.md \
    --settings lane/settings.json \
    --mcp-config lane/mcp.json \
    --permission-prompts none > run.out
find "$HOME" -type f -exec sha256sum {} + | sort -k2 > after.txt
diff before.txt after.txt > home-writes.diff || true
grep -E 'AGENTS\.md|CLAUDE(\.local)?\.md|/memory/|/synced/|/skills/|\.mcp\.json' reads.log > state-reads.txt || true

--permission-prompts none (2.1.259 or later) denies anything that would prompt and tells the model nobody can approve it, so the run never waits on an approver who isn’t there.

Then plant canary tokens, our technique rather than a vendor feature: a distinct marker line in each state source you control (the AGENTS.md, a memory note, a user-level skill, a global Grok note) asking the model to end its reply with that marker. The trace proves a file was opened; a token in the output proves the model used it.

When the recorder itself fails (no trace file, an empty snapshot, an init event that never arrived), fail the lane. Missing evidence is not a pass.

Step 4: Diff the two runs and fail on anything undeclared

Put both runs side by side against the manifest. Here is a first pass on a lane still launched with plain claude -p; the values are illustrative.

Two rules decide the verdict. Any item in either run that isn’t in the manifest fails the lane, even when both runs agree; two contaminated homes agreeing is not cleanliness. And any difference between the runs fails the lane even for a declared item, because an input that loads on one machine and not the other is a reproducibility bug. Keep the verdict and the evidence files in the run record.

Illustrative. Switching off sync and memory removes the account-borne state; bare mode removes the rest, AGENTS.md included in a 2.1.278 test.

Step 5: Make Claude Code bare mode the launch line and pass everything by flag

For Claude Code, the documented fix for most of that table is one flag. The headless docs: “Add --bare to reduce startup time by skipping auto-discovery of hooks, skills, custom commands, subagents, plugins, MCP servers, auto memory, and CLAUDE.md.” And the line that makes it the lane default: “Bare mode is useful for CI and scripts where you need the same result on every machine.”

Compare the plain -p default, which the same page warns about: it “runs the hooks in a project’s .claude/settings.json and connects the servers in its .mcp.json, even in a folder you’ve never trusted”, with no workspace trust dialog and no per-server approval prompt.

Screenshot: Claude Code Docs, “Run Claude Code programmatically” (undated), captured Sep 21, 2026.

Bare mode changes authentication. “In bare mode, Claude Code never reads OAuth credentials or the system keychain”, so a subscription login won’t authenticate the lane. Set ANTHROPIC_API_KEY from your secret store or supply an apiKeyHelper in the --settings JSON; Bedrock, Google Cloud’s Agent Platform and Microsoft Foundry keep reading their own provider credentials.

The run gets Bash, file read and file edit, and everything else arrives by flag: --append-system-prompt-file, --settings, --mcp-config, --agents, and --plugin-dir for a plugin you reviewed. That flag line should match the manifest line for line.

Bare mode stops discovery at one wall. The amber line is why you still run the differential.

Three edges to know before you call a bare lane clean.

• An --add-dir folder brings its skills. Bare mode loads skills from that folder’s .claude/skills/, while still skipping its .claude/commands/ and .claude/agents/. Declare those skills in the manifest or don’t add the folder.
• Bare mode skipped AGENTS.md in a capture test. The bare-mode docs name CLAUDE.md as skipped and never mention AGENTS.md, which ships as the built-in agents-md plugin. A Sep 21 test on Claude Code 2.1.278 settled it for that version: with an AGENTS.md-only repo holding a canary token and the API calls captured locally, plain claude -p sent the file from the second session on, as step 2 predicts, and claude --bare -p never sent it in two runs. One version on the direct API path is not a guarantee, so rerun the fixture after every upgrade: a clean home run twice, the canary repo, and claude --bare -p "what are your project instructions".
• Bare becomes the default later. The docs say --bare “will become the default for -p in a future release.” Put it in the flag line now, so lanes that quietly rely on discovery break on your schedule rather than the vendor’s.

Step 6: When a lane can’t use Claude Code bare mode, switch each source off by name

Some lanes need a subscription login, or a plugin that only discovery finds. Those lanes keep plain -p and switch sources off one at a time, from a scope the repo can’t override.

• Account sync. Set syncClaudeAiSkills: false and syncClaudeAiPlugins: false in user, local or managed settings, or a file passed with --settings. Claude Code honours only false and ignores it in the committed .claude/settings.json; one plugin can be switched off with "<name>@synced": false in enabledPlugins. A lane that ranks skills ranks whatever sync delivered; soft-ranking skills with Jev assumes you chose that roster.
• Auto memory. Set CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 or autoMemoryEnabled: false, or point autoMemoryDirectory at a directory the lane owns (step 7).
• Instruction layers. ~/.claude/CLAUDE.md, a managed CLAUDE.md and .claude/rules/ keep loading alongside AGENTS.md. A CLAUDE.local.md counts as a CLAUDE.md, so adding one stops the AGENTS.md read, and so do disableAllHooks and allowManagedHooksOnly, because the reader ships as a plugin. To pin the choice, set pluginConfigs → agents-md@builtin → instructionFiles to claude-md (or claude-md-and-agents-md) in user or managed settings; “Claude Code ignores it in project and local settings files.”
• Plugin timing. Set CLAUDE_CODE_SYNC_PLUGIN_INSTALL=1. Without it, plugins “install in the background and may not be available on the first turn”, so turn one sees a different plugin set from turn five.

An illustrative user-settings shape for such a lane’s runner, alongside CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 and CLAUDE_CODE_SYNC_PLUGIN_INSTALL=1 in its environment:

{
  "syncClaudeAiSkills": false,
  "syncClaudeAiPlugins": false,
  "autoMemoryEnabled": false,
  "pluginConfigs": {
    "agents-md@builtin": { "instructionFiles": "claude-md" }
  }
}

Hooks and .mcp.json servers still run under plain -p. Keep the permission deny rules and sandbox that restricted mode as fleet policy canary-tests as the wall behind every lane in this piece. The differential tells you what a run read; it does nothing to stop a run acting on it.

Step 7: Give memory without an off switch an empty or versioned directory

Grok Build documents no memory off switch, and its notes include a global scope that applies to every project. So control what exists when the run starts.

1. Fresh or restored home per run. Start each Grok lane from an empty home, or restore its notes from a versioned copy the lane’s owner reviewed. Grok’s /dream pass also runs on its own in the background, so snapshot notes at run start rather than trusting the previous run’s end state.
2. Treat new notes as output. Step 3 already hashes them; route new or changed notes to review before a later run can read them. Grok says task state and secrets are left out of notes. Confirm that in the diff, not on the vendor’s word.
3. Know what outranks a note. “Instructions in the current conversation take precedence over anything in a note”, so a lane prompt that states a rule wins. It doesn’t help where the prompt is silent.
4. Same pattern on Claude Code. Where a lane genuinely needs memory, set autoMemoryDirectory to a directory under version control, reset it from a pinned commit before each run and review its diff after. That also fixes the shared-worktree trap.

Memory outlives compaction, too. Claude Code’s context-window docs list auto memory as “Re-injected from disk” after a compaction (Claude Code context window docs), so an undeclared note returns after every compaction the lane’s contract allows.

Step 8: Re-run the differential after every CLI upgrade

Both Claude Code changes above arrived as ordinary version bumps that touched no config file. Add the differential to the upgrade gate that the CLI upgrade canary runs: the canary diffs what the lane was served (model, effort, compaction point), and this diffs what it read. After every bump, run the clean home twice, since the new version’s first session is when flag-gated features go missing, and fail the upgrade on any new undeclared read or write.

Where the clean-versus-used test lies to you

A leaked environment variable. CLAUDE_CODE_DISABLE_AUTO_MEMORY=0 forces auto memory on “even when --bare mode or autoMemoryEnabled: false would otherwise disable it”. Signal: memory reads or writes in a bare run. Fix: the environment allowlist from step 1, recorded with every run.

A clean home that’s really a first session. Signal: clean run 1 and clean run 2 disagree on AGENTS.md or synced content. Fix: judge run 2 and keep run 1 as evidence.

A shared memory directory. Signal: memory reads on a brand-new worktree. Fix: a lane-owned autoMemoryDirectory, or memory off.

The CLAUDE.local.md flip. Signal: the instruction-file set changes with no commit touching AGENTS.md. Fix: the instructionFiles pin from step 6.

An opt-out in the wrong file. Signal: skills/synced/ fills up although the repo’s settings say false. Fix: move the opt-out to user, managed or --settings scope.

The invisible read. Signal: the model follows an instruction that no file in /context contains. Fix: the OS trace and canary tokens from step 3.

The wrong provider path. Signal: the test passes on an API key while a production lane on Bedrock or behind a gateway loads different instructions. Fix: test on the path production uses.

Reproducible runs belong to the fleet layer

None of this lives in the model or the prompt. The manifest, the two homes, the recorder and the fail rule belong to the layer that launches lanes, holds their credentials and keeps their evidence, the same layer that owns kill switches and approvals. A fleet replay is only evidence if you know what the original run read; the differential turns that input list from a guess into a record.

Vendors will keep adding state that makes interactive sessions smarter by default, which is good for a person at a keyboard. Unattended lanes need the opposite default: nothing loads unless someone wrote it down.

FAQ

Does claude --bare read AGENTS.md?

Not on Claude Code 2.1.278, in a Sep 21 capture test: plain claude -p sent the AGENTS.md to the API from the second session on, and claude --bare -p never did. The docs name only CLAUDE.md as skipped, so rerun the test after each upgrade with a canary token in an AGENTS.md-only repo.

Sources

• Claude Code changelog — 2.1.275 claude.ai sync (Sep 17, 2026); 2.1.277 AGENTS.md support (Sep 18, 2026)
• Claude Code headless docs — bare mode, authentication, the --add-dir exception, system/init, the untrusted-folder warning
• Claude Code memory docs — AGENTS.md loading rules and unavailability, auto memory path and switches
• Claude Code settings reference — syncClaudeAiSkills, syncClaudeAiPlugins, autoMemoryEnabled, autoMemoryDirectory
• Claude Code environment variables — feature-flag fetching, the first-session rule, CLAUDE_CODE_DISABLE_AUTO_MEMORY, CLAUDE_CODE_SYNC_PLUGIN_INSTALL
• Claude Code context window docs — what compaction re-injects
• Grok Build memory — per-turn capture, workspace and global scopes, new sessions only (Sep 16, 2026)

Two Anthropic products moved permission decisions onto Anthropic’s servers in the nine days to Sep 19. The fleet question is no longer whether to approve a call. It is which of the vendor’s verdicts still need you at all, and where the rest belong.

By Tuesday you can answer that for every lane. Each vendor’s evaluation lands in one schema. Allows and denials go to an evaluation log as evidence. Only calls the vendor actually paused reach your approval queue, each with an expiry you set. Tools a person must see first move to the vendor’s native ask. And every call whose verdict you cannot see is written down as unavailable instead of assumed.

Chatbots suggest; agents act. The approval queue used to double as the record of what was decided. Now most decisions happen on the vendor’s side of the wire, and the queue sees only the leftovers.

Sep 10 and Sep 19: the Claude Managed Agents permission policy gets auto, and Claude Code goes server-side

On Sep 10, 2026, Anthropic’s platform release notes added auto to the Managed Agents permission policies, next to always_allow and always_ask. Under auto the server evaluates each agent or MCP tool call and runs it, denies it, or pauses it for your approval when it reaches no determination. The agent toolset defaults to always_allow, MCP toolsets to always_ask, and nothing uses auto until you set it. The same notes shipped version 1.32.0 of the ant CLI with ant beta:sessions connect, which attaches a terminal to a running session so you can follow it and allow or deny waiting calls.

The verdict rides on the event. Under any policy, every agent.tool_use and agent.mcp_tool_use event carries evaluated_permission with a value of allow, ask or deny, and most events also carry an evaluation object. Under auto, a pause carries the reason_code indeterminate and a denial carries high_risk. A denial is final: “The session keeps running, and your client cannot override the denial.” The docs are just as blunt about the other direction.

“auto is not a human checkpoint. If the server determines that a call is safe, the call runs before anyone sees it, and its effects might not be reversible. If a person must review a tool’s calls before they run, configure always_ask on that tool.”

Screenshot: Claude Platform Docs, “Permission policies - Claude Platform Docs” (undated), captured Sep 21, 2026.

Nine days later, Claude Code 2.1.278 (Sep 19) switched auto mode for Claude API and Enterprise users, and on Bedrock, Vertex, Foundry and gateways, to a server-side classifier “which does not charge for classifier overhead”. The opt-out, CLAUDE_CODE_AUTO_MODE_SERVER=0, applies on Bedrock, Vertex, Foundry and gateways, and the permission-modes doc says the variable isn’t read on a direct connection to the Anthropic API. Four days earlier, 2.1.273 had set those three clouds to the local classifier by default. How your own classifier stacks against Claude Code’s is covered in the Jev confidence-gate runbook. What matters here is what Claude Code tells you afterwards: its denials, and never which allows its classifier made.

A third source, GitHub Copilot’s enterprise-managed ask, comes with its own rules about what can’t satisfy it. The cross-harness override test owns that one.

Human-in-the-loop queues that don’t become rubber stamps already folds your CLIs into one tiered queue with expiry and budgets. This runbook sits upstream of it. It decides which vendor verdicts get into that queue in the first place.

Step 1: Write one verdict schema every lane reports into

Keep one row per tool call per verdict source, append-only. A call that pauses and is later answered gets two rows: the vendor’s ask, then the resolution. Use the same fields on every lane, whichever vendor made the call.

static_policy covers anything you configured and versioned, including hooks and a classifier gate of your own. vendor_classifier is a verdict the vendor’s model made and told you about. human is a person answering a pause.

unavailable is a first-class value in both columns, and the reason is the rest of this runbook. A verdict you never received is not an allow. The habit of writing one evidence line per gate decision comes from pre-action gates; this schema extends it to decisions somebody else’s server made.

{"ts":"2026-09-21T14:02:07Z","lane":"billing-api","session_id":"<vendor session id>","event_id":"<vendor event id>","tool_use_id":"<vendor call id>","tool":"bash","call_ref":"calls/2026-09-21/billing-api/0412.json","call_sha256":"9f2c…","verdict":"allow","decided_by":"vendor_classifier","vendor_raw":{"evaluated_permission":"allow"},"source":"managed-agents:events","policy_version":"agent-def@14","harness_version":"managed-agents-2026-04-01","classifier_location":"server"}

The row is illustrative. Store the exact call input where your transcripts already live, under the same access rules: tool inputs carry file contents and sometimes secrets, and a hash alone can’t tell a reviewer what ran.

Step 2: Map Claude Managed Agents permission policy fields, and no others

Your normalizer reads three event types. On agent.tool_use and agent.mcp_tool_use, evaluated_permission is the verdict. decided_by comes from the policy you configured for that tool, which is why policy_version sits in the row: an allow under always_allow came from your configuration, and an allow under auto came from the server’s judgment.

Missing never means allow. The evaluation object is absent when the agent names a tool the session doesn’t enable (a deny with no evaluation) and on events recorded before the field existed. Unknown values stay raw: the docs tell clients to tolerate an evaluation.type or reason_code they don’t recognize, so keep it in vendor_raw and leave decided_by at unavailable until you update the map. Custom tool events carry neither field, because permission policies don’t govern custom tools.

An answered pause gets its second row from the confirmation you send (Step 5): same event_id, allow or deny, decided_by: human.

Step 3: Map Claude Code honestly, which mostly means denials

Claude Code gives you two documented sources, and neither can name a classifier allow.

The PermissionDenied hook runs when auto mode denies a tool call, including a denial made without a classifier verdict. It receives tool_name, tool_input, tool_use_id and a reason (plus mcp_server for MCP tools). “This hook only fires in auto mode”: a denial you click, a PreToolUse block or a matching deny rule never reaches it. Its only output is a request to retry, and exit codes are ignored, so it is a logging point, never a gate.

The OTel tool_decision event in the monitoring doc records a decision of accept or reject and a source of config, hook, user_permanent, user_temporary, user_abort or user_reject. config lumps together settings, managed policy, flags and the active permission mode, and the doc is plain about it: “The event doesn’t indicate which of these sources matched.” No documented field or hook distinguishes a classifier allow from a rule allow, so no row of yours should claim one.

Screenshot: Claude Code Docs, “Hooks reference - Claude Code Docs” (undated), captured Sep 21, 2026.

The logger for the first two rows records and cannot block.

# log_denial.py: illustrative PermissionDenied command hook; a logger, not a gate
# LANE and LANE_CLI_VERSION are set by your runner, not by Claude Code
import hashlib, json, os, sys, time
e = json.load(sys.stdin)
reason = e.get("reason", "")
no_verdict = reason.startswith("Auto mode could not evaluate") or reason == "Classifier unavailable"
row = {
    "ts": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
    "lane": os.environ.get("LANE", "unknown"),
    "session_id": e.get("session_id"),
    "tool_use_id": e["tool_use_id"],
    "tool": e["tool_name"],
    "call_sha256": hashlib.sha256(json.dumps(e["tool_input"], sort_keys=True).encode()).hexdigest(),
    "verdict": "deny",
    "decided_by": "unavailable" if no_verdict else "vendor_classifier",
    "vendor_raw": {"reason": reason, "mcp_server": e.get("mcp_server")},
    "source": "claude-code:PermissionDenied",
    "harness_version": os.environ.get("LANE_CLI_VERSION", "unknown"),
}
with open(os.path.expanduser("~/.fleet/verdicts.jsonl"), "a") as f:
    f.write(json.dumps(row) + "\n")

Then record where the classifier ran, per session. Per the classifier billing doc, /status has an “Auto mode server” row that reads Enabled while the server decides and Disabled after Claude Code falls back to its own billed classifier requests, which happens when a gateway or proxy strips or rewrites headers, drops unrecognized request fields or edits responses. Headless lanes get the fallback notice on stderr under -p and as a system warning in stream-json; capture it and set classifier_location to local. Pro, Max and Team plans never see that notice, so its absence proves nothing there: leave those sessions at unknown. Keep harness_version on every row, because Bedrock, Vertex and Foundry sessions on 2.1.273 through 2.1.277 default to the local classifier and 2.1.278 onward to the server.

One trap: /permissions lists auto-mode denials under Recently denied, but per the auto mode configuration doc not the no-verdict ones. Build the denial log from the hook.

Any lane whose harness documents no verdict field gets unavailable in both columns until it does. Don’t reconstruct a vendor verdict from timing, from a missing prompt, or from a transcript line that reads like approval.

Step 4: Split the stream: evidence for allow and deny, the queue for ask

This split is the answer to the headline. Of the four verdicts, exactly one still needs a person.

Allow and deny are evidence. Ask is the only verdict that still waits for a person. Unavailable is a gap you close with your own gate.

Allows and denials are evidence, and evidence has a retention clock you don’t control on a vendor-hosted session. Export the evaluation log on a schedule, the same way you’d export the agent audit trail before access changes. The unavailable share per lane is a coverage gap, and it belongs on the weekly page from the three oversight numbers, printed rather than hidden.

Illustrative: modeled shares, not measured data. On a Claude Code auto-mode lane most allows land in unavailable, because no documented field names the classifier.

Don’t try to fix a deny by sending a confirmation. The API refuses it: “If you send a user.tool_confirmation for an event whose evaluated_permission is not ask, the API rejects it with a 400 error.” A spike of 400s in your confirm path means your queue is admitting events it shouldn’t.

Step 5: Answer each pause through the vendor’s own confirm path

A Managed Agents pause emits session.status_idle with stop_reason.type: requires_action and the blocking IDs in stop_reason.event_ids. Build one queue item per blocking event and carry the lane, the call pointer, the vendor’s reason_code and the session ID on it. The approver’s answer goes back as a user.tool_confirmation with tool_use_id, a result of allow or deny, and an optional deny_message.

{"type":"user.tool_confirmation","tool_use_id":"<id of the paused call>","result":"deny","deny_message":"Pushes to main need a release ticket. Open one and retry."}

Illustrative body; the field names are from the docs, and the transport is whatever your client already uses. For a person at a terminal, ant beta:sessions connect covers the same ground, and its --web flag serves the Console’s session viewer locally.

Answer only through that path; a call your runner executes outside the session has no vendor verdict and no place in the event stream. Answer each blocking event separately, so one approval can’t cover a different call that paused in the same idle. Write the resolution row the moment the confirmation is accepted, with the approver’s identity beside decided_by: human.

On Claude Code lanes the confirm path is the session’s own permission prompt. Your record of it arrives as a tool_decision with a user_* source.

Step 6: Put your own expiry on every native pause

“The session waits indefinitely for a response.” That line describes the vendor’s behaviour, and nothing obliges you to copy it. The docs describe no timeout on a pause, so the clock is yours.

Set expiry per consequence tier, using the tiers your approval queue already runs. When a pause expires, send result: "deny" with a deny_message naming the expiry, then write the row as deny, decided_by: static_policy, with the expiry rule’s version in policy_version. A reviewer who clicks later should hit a closed item. Don’t count on the vendor to reject a second confirmation for the same call; close the item on your side.

Count expiry denials per lane each week. A lane whose pauses keep expiring has the wrong tier, a thin reviewer rota, or a tool on the wrong policy.

Step 7: Move anything a person must see first to always_ask

An auto allow runs before anyone sees it, and an auto deny can’t be overridden. That leaves a person exactly one lever under auto: the pauses the server chooses to raise. Anything a person must see before it runs goes on always_ask, which pauses every call to that tool.

Walk each lane’s tool list with this checklist:

1. Irreversible effects. Pushes to protected branches, deploys, deletes, outbound messages, anything that moves money. These go on always_ask, or off the agent entirely.
2. Tools reachable by relayed end-user text. What you post in user.message counts as your intent and can lead the server to allow a call it would otherwise deny. Relay untrusted end-user input there and the server reads it as your intent too; Anthropic’s advice is always_ask on tools that user must not run unreviewed. The server doesn’t take intent from tool results, fetched pages, MCP responses or messages between session threads, so the risk is the relay you built.
3. MCP toolsets. They default to always_ask. Moving one to auto is a decision with a name and a date on it.
4. The agent toolset. It defaults to always_allow, which stamps allow on every call without judging any of them. Choose auto or always_ask per tool on purpose rather than inheriting the default.

The normalizer, the log and the queue from Steps 1 to 6 are records and routing. They don’t enforce anything. If your pipeline drops an event, the call it described still ran or still stopped exactly as the vendor decided. The walls are the vendor-side policy (always_ask, disabled tools), your harness deny rules and the sandbox under the agent. Watch the pipeline itself: compare event counts per session in the vendor stream against rows in your log, and alert when they diverge.

Step 8: Gate custom tools in the app that runs them

agent.custom_tool_use events carry neither evaluated_permission nor evaluation. Your application executes custom tools, so your application is the gate, and the vendor verdict for those calls is permanently unavailable.

Write your gate’s decision into the same schema with decided_by set to static_policy or human, never vendor_classifier. Fail closed: if the gate errors or times out, the row reads deny, the error goes in vendor_raw, and the tool doesn’t run.

Four ways a verdict pipeline misleads you, and the signal for each

Absent read as allow. A mapper defaults a missing evaluation or evaluated_permission to allow. Signal: allow rows with an empty vendor_raw. Fix: map absence to unavailable, and fail the mapper’s tests on any default.

Relayed text talks the server into an allow. An app forwards customer messages as user.message and the server reads them as your intent. Signal: auto allows on sensitive tools in sessions whose user.message came from a relay. Fix: always_ask on those tools, then re-read Step 7.

The classifier moved and nobody noticed. A CLI upgrade or a header-rewriting proxy changes who decided. Signal: classifier_location flips between server and local within a lane, or the billed-fallback notice appears in headless stderr. Fix: record it per session and treat an unexpected flip as a change event.

The record goes quiet. A hook stops firing or telemetry export breaks, and the log looks calm. Signal: rows per session fall against the vendor’s event count, or a lane shows zero denials for a week. Fix: alert on the divergence, and remember the enforcement never lived in the log.

One verdict schema is how a fleet keeps its own record

Every vendor will keep shipping its own permission dialect: a server-side policy here, a hook that fires only on denials there, a managed ask with its own override rules somewhere else. None of them will normalize the others for you. The schema, the split and the expiry belong in the layer that runs the whole fleet, beside the kill switch and the session inventory, which is the job of a multi-agent command center rather than any one vendor’s console.

Run the split for a week. Most rows will be evidence. A few will be real asks with a clock on them. The unavailable count is the honest number, and it is the one to shrink.

FAQ

Does Claude Managed Agents auto mode replace human approval?

No. Anthropic’s docs say auto is not a human checkpoint: a call the server judges safe runs before anyone looks, and your client cannot override a denial. Only calls the server can’t decide pause for you. Put always_ask on any tool a person must review before it runs, and give those pauses your own expiry.

Can I see which tool calls Claude Code’s auto mode classifier allowed?

Not from any documented field. The PermissionDenied hook fires on auto-mode denials only, and the OTel tool_decision event reports permission-mode decisions under source: "config" without saying which source matched. Log those allows with decided_by: unavailable rather than claiming a classifier verdict you never received.

Sources

• Claude Platform Docs: Permission policies — policy types, verdict fields, confirmations, custom tools, intent
• Claude Platform release notes — Sep 10, 2026: auto; Ant CLI 1.32.0
• Claude Code changelog — 2.1.278 (Sep 19, 2026) and 2.1.273 (Sep 15, 2026)
• Claude Code hooks reference — PermissionDenied
• Claude Code monitoring — OTel tool_decision
• Claude Code permission modes — server classifier default and opt-out scope
• Claude Code auto mode classifier billing — fallback, notice, /status row
• Claude Code auto mode configuration — Recently denied

Uninstalling the package doesn’t fix it either. npm removes the files it unpacked. It keeps no record of what a script wrote into your home directory, your Task Scheduler or your PATH.

Treat unauthored hooks like any other persistence mechanism: inventory, alert, remove in order, prove. By Tuesday, every agent host should have an off-box baseline of its hooks, logon tasks, autostart entries and PATH shims, with the resolved path and hash of everything each one launches.

A change nobody authored pages someone. Agent-helper packages install only from an allowlist, in a project, through npx or globally. And every cleanup ends with evidence that survives a reboot.

Chatbots suggest; agents act. A hook acts even when nobody is prompting the agent, because the harness launches it on the event, with the user’s rights, under the name of a tool you trust.

Sep 6: 18 agent-helper packages on npm, Claude Code hooks malware among them

On Sep 6, 2026, AgentGate published a list of 18 npm packages it calls malicious and says were still installable that day. AgentGate sells an agent-config scanner, so read it as vendor research. Three entries map onto this runbook’s surfaces. llm-interceptor “registers an MCP server in ~/.cursor/mcp.json, runs claude mcp add, installs a Claude Code SessionEnd hook, and on Windows creates a logon task.” remote-claude-daemon takes tasks over an outbound connection and hands them to local agents “with permission prompts explicitly bypassed.” opencode-optimised-toolings “renames your on-PATH opencode aside and installs its own build in its place”.

OSV’s records, with text from Amazon Inspector, add detail. MAL-2026-13370 says llm-interceptor runs its setup before any consent dialog, sends a heartbeat every 15 minutes regardless of consent, and “installs three redundant Windows persistence mechanisms”: a scheduled task with an ONLOGON trigger, a 5-minute pulse and RestartOnFailure; an HKCU Run key; and a Startup-folder shortcut. MAL-2026-13455 says remote-claude-daemon “spawns the local claude binary with --continue -p --dangerously-skip-permissions and the remote-supplied prompt as input”.

MAL-2026-13452 says the OpenCode package also rewrites ~/.config/opencode/opencode.jsonc, injects a marked block into AGENTS.md and pins itself in tui.json. MAL-2026-5789 says claude-cup runs on the first npx claude-cup and then on every Claude Code tool call once its hooks are in.

Screenshot: OSV, “MAL-2026-13370 - OSV” (Aug 5, 2026), captured Sep 21, 2026.

On Sep 21 we checked the npm registry: all four still resolve, at the latest versions AgentGate listed (0.4.1, 0.7.5, 6.5.2 and 0.9.12). Still resolving means npm hadn’t removed them; it is not a separate finding of malice.

The same day, an OSV query by exact version returned no advisory for remote-claude-daemon@0.7.5 or opencode-optimised-toolings@6.5.2, the current latest of each. A scanner that matches OSV by version would pass both. Step 3 turns on that gap.

The thesis has a primary source too. Mandiant’s AI Risk and Resilience Report (September 2026) includes Case study 3, “Subverting assistant CLI hooks for native remote code execution”. At an IT and software development organization, Mandiant writes, “a threat actor had successfully poisoned an internal AI repository and tampered with the assistant’s underlying CLI hooks.” Its controls include signing and verifying assistant binaries, CLI helpers, plugins and MCP servers before they run, and “multi-party approvals and strict code review policies for all skill/hook modifications”. That second control is how this runbook defines “authored”.

Screenshot: Google Cloud, “Mandiant AI Risk and Resilience Report 2026” (September 2026), captured Sep 21, 2026.

On Sep 14, Claude Code 2.1.271 added --accept-command <sha256> to claude plugin install and claude plugin update, “to accept exactly the command a previous --json run displayed, instead of -y”. The plugin marketplace docs set its scope: “Claude Code runs only the command it showed, for the archive URL it showed.” That is command approval. It doesn’t hash what the plugin contains, and it says nothing about what the plugin writes into your settings once it runs.

Why Claude Code hooks malware outlives the package that wrote it

A hook is an entry in a settings file telling the harness to run something when an event fires. Claude Code’s hooks reference lists five hook types, command, http, mcp_tool, prompt and agent, and the event decides when each one runs; a SessionEnd hook runs as every session closes. Once a package writes one, removing the package doesn’t remove the entry, and the harness keeps launching whatever it names.

An MCP registration gets its command started by every client that reads the config. A logon task runs at each sign-in. A PATH shim runs whenever anyone, human or agent, types the tool’s name.

That is why removing the package is not eradication, and why a scan of node_modules comes back clean on an infected host. The persistence lives in four places npm never tracked.

Marketplace hygiene for plugins and MCP servers re-verifies entries you approved, and plugin pinning has its own runbook (step 2 links it). Neither covers what a package writes after install that nobody approved, or proving it’s gone.

Step 1: Baseline every persistence surface, off the box

Keep one record per host, gathered by a collector the host runs and stored where the host can’t rewrite it. The unit is not the entry. It’s the entry plus the resolved path and SHA-256 of whatever the entry launches, because a shim swap leaves every entry’s text unchanged and alters only a hash.

Four rules make the record worth diffing.

Resolve before you hash. For a command like node C:\Users\dev\.tool\index.js, hash both the interpreter and the script. For a shortcut, hash its target. For a bare name, resolve it through the PATH the harness sees, which may not match your interactive shell’s.

Hash every PATH hit, in order. OSV says that after the OpenCode swap, later opencode runs “execute the author-built binary under the trusted CLI name”. The first hit is what runs; the rest tell you what moved. A file beside the binary with a name like .alonix-toolings-backup is a finding on its own.

Record strings where there is no file. An http hook has a URL and an mcp_tool hook has a server name. There’s nothing local to hash, so the string itself is the value that must not change.

Ship it off-box, append-only. A baseline kept on the host is a notebook kept by the suspect. Push every run to a store the host’s user can’t edit, include the collector’s own hash in the record, and treat a missed check-in as an alert.

# collect-persistence.ps1 - illustrative shape; one JSON line per entry, pushed off-box
$rows = New-Object System.Collections.Generic.List[object]
function Sha($p) { if ($p -and (Test-Path -LiteralPath $p)) { (Get-FileHash -LiteralPath $p -Algorithm SHA256).Hash } }

# Agent hooks: repeat for every settings layer and every CLI's hook config
$cfg = Get-Content "$env:USERPROFILE\.claude\settings.json" -Raw | ConvertFrom-Json
foreach ($ev in $cfg.hooks.PSObject.Properties) { foreach ($g in $ev.Value) { foreach ($hk in $g.hooks) {
  $rows.Add(@{ surface='hook'; event=$ev.Name; matcher=$g.matcher; type=$hk.type; cmd=$hk.command; url=$hk.url }) } } }

# Logon and boot tasks
Get-ScheduledTask | Where-Object { $_.Triggers | Where-Object { $_.CimClass.CimClassName -match 'Logon|Boot' } } |
  ForEach-Object { $t = $_; foreach ($a in $t.Actions) {
    $rows.Add(@{ surface='task'; name="$($t.TaskPath)$($t.TaskName)"; exe=$a.Execute; args=$a.Arguments; sha=(Sha $a.Execute) }) } }

# Run key values and Startup shortcuts
(Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run').PSObject.Properties |
  Where-Object Name -notlike 'PS*' | ForEach-Object { $rows.Add(@{ surface='run'; name=$_.Name; value=$_.Value }) }
$sh = New-Object -ComObject WScript.Shell
Get-ChildItem "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup" -Filter *.lnk | ForEach-Object {
  $tgt = $sh.CreateShortcut($_.FullName).TargetPath; $rows.Add(@{ surface='startup'; lnk=$_.Name; target=$tgt; sha=(Sha $tgt) }) }

# Every PATH hit for each agent CLI, in resolution order
foreach ($n in 'claude','opencode','codex') {
  Get-Command $n -All -ErrorAction SilentlyContinue | ForEach-Object { $rows.Add(@{ surface='path'; name=$n; path=$_.Source; sha=(Sha $_.Source) }) } }

$rows | ForEach-Object { $_ | ConvertTo-Json -Compress }   # pipe to the append-only store, never only to local disk

The same shape works in shell on macOS and Linux. OSV’s llm-interceptor record describes Windows persistence only. That’s a fact about one record, not about the next package, so baseline the user-level autostart locations on every OS you run.

Documented behaviour only, from OSV records (text from Amazon Inspector) and AgentGate. A dash means the sources don’t describe it, not that the package doesn’t do it. Each column is a section of your baseline.

Step 2: Alert on any change you did not author

“Authored” needs a definition a script can check. Here it means a change that reached the host through your change path, carrying a reviewed record that names the host group, the surface, the entry and the expected hash, approved by someone other than the requester. That is Mandiant’s multi-party approval for hook changes, applied to all four surfaces. Everything else is unauthored, including a legitimate plugin adding a hook during an update nobody announced.

Run the collector at logon, on a timer (every 15 minutes is an illustrative starting point), and right after any install or update of an agent CLI, plugin or helper package. The post-install run earns its keep, because it lands the diff next to the command that caused it.

Plugins add hooks legitimately, so make the update itself the authored event. In automation, run claude plugin install or claude plugin update with --json, have a person approve the command it displays, and pass that run’s sha256 to --accept-command instead of -y. Record the diff you expect, run the update, then diff for real.

The flag guarantees the command and archive URL a person saw; the diff tells you what that command wrote. Pinning the plugin itself to a commit is covered in the Plugin4Shell pin-and-verify runbook.

A new MCP registration is a persistence event and an inventory event at once. Alert on it here, then reconcile it through your MCP server inventory ritual. An entry nobody can explain gets the shadow MCP treatment.

Step 3: Allowlist agent-helper packages by name, for every way npm runs code

AgentGate says of its 18: “Each has an upstream OSV/GHSA record”. Per package, that holds. Per version it doesn’t, because two of the four current latest versions returned nothing from OSV on Sep 21.

A denylist knows only the versions someone has already recorded. Allowlist by name, then decide which versions of each name you accept.

The allowlist also has to cover every door, because npm lifecycle scripts run on local, npx and global installs alike. llm-interceptor’s payload starts in postinstall. claude-cup’s runs the first time someone types npx claude-cup, with no lockfile anywhere near it. llm-interceptor can reinstall itself globally on its collector’s instruction.

A lockfile review covers one of those three doors.

Enforce it where the doors meet: the registry path your hosts resolve through. In its case study 1, Mandiant recommends routing “all dependency traffic through secure, internal repositories” and validating AI-recommended dependencies “against cryptographic checksums and approved allowlists”. An internal registry or proxy that serves only allowlisted names does both, for every install mode.

# agent-helpers.allow.yaml - illustrative shape; served by the internal registry, reviewed like code
- name: "@your-org/agent-lint"
  versions: "2.4.x"
  modes: [project, npx]            # a global install needs its own approval
  expected_writes: []              # surfaces it may touch at install or first run; empty = none
  approved_by: [owner-a, owner-b]  # two names: the multi-party rule
  reviewed: 2026-09-21
- name: "@your-org/docs-mcp-server"
  versions: "1.9.x"
  modes: [project]
  expected_writes: [mcp_registration]
  approved_by: [owner-a, owner-c]
  reviewed: 2026-09-21

The expected_writes field ties this step to step 1. If installing an allowlisted package produces a diff outside what its entry declares, that pages someone.

Decide what counts as an agent helper by behaviour, not by name: anything that writes agent config, registers MCP servers, wraps or replaces an agent CLI, or offers to meter, proxy or remote-control one. Registry keywords such as mcp, claude-code and remote-desktop, all used by packages on the list, can route a package to review. They don’t detect anything.

Be honest about the edges. A developer who points npm straight at the public registry, or copies a tarball by hand, walks around the allowlist; that’s why step 1 exists. Turning install scripts off is a sensible extra wall, but it does nothing about a payload that runs when invoked. The publish side of the same supply chain, keeping your own agents from pushing a poisoned version, is covered in stage-only npm tokens for agents.

Step 4: Eradicate in order, reboot, and prove the hook, task and shim stay gone

Order matters, because llm-interceptor is built to come back: RestartOnFailure, a 5-minute pulse, three autostart paths and a self-update. Remove what respawns before you remove what it respawns.

1. Pull the host from agent work. Stop its sessions, take its lanes off the scheduler, and block outbound traffic to anything but your management plane. OSV says the heartbeat fires every 15 minutes; make the next one fail.
2. Disable the respawners before killing processes. Disable the scheduled task and export its definition as evidence before you delete it. Remove the Run value and the Startup shortcut. Only then stop the processes they launch.
3. Remove the agent-side entries. Delete the hook from every settings layer, not just ~/.claude/settings.json. Remove the MCP registrations from every client, including ~/.cursor/mcp.json and Claude Code’s own list.
4. Restore the trusted binaries and files. Delete the impostor on PATH, reinstall the CLI from your approved source, and check its hash against the baseline before removing leftovers like .alonix-toolings-backup. Restore opencode.jsonc and tui.json from the baseline copy. Search every repo on the host for injected AGENTS.md blocks, committed ones included, because an instruction-file injection can leave the host inside a pushed commit.
5. Remove the package from every scope. That means project node_modules, global installs under every Node version on the host, and the npx cache.
6. Assume what it read is gone. llm-interceptor posts transcript turns to its collector. claude-cup harvests .aws/credentials, .npmrc, .git-credentials, SSH keys and .env files. Rotate whatever those held; credential brokering is its own discipline and out of scope here.
7. Reboot and fire every trigger. Log on as the affected user, since an ONLOGON trigger needs a logon. Start and end one agent session so any SessionEnd hook fires, and make one tool call. Run each agent CLI by name once. Then leave the host up for at least two heartbeat intervals, which is 30 minutes against OSV’s 15-minute heartbeat.
8. Diff, then diff again. Re-run the collector against the pre-incident baseline. The proof passes with zero unauthored delta and no outbound connection to the collector during the wait. Repeat at 24 hours and after the next agent CLI update.

Keep the proof as a record, not a feeling:

Four surfaces, one diff. The loop only closes when the diff comes back empty after a reboot and every trigger has fired.

Where the baseline lies to you, and what gives it away

The baseline is detection, not a boundary. It fails in specific ways, and each failure leaves a signal.

The collector runs on the compromised host. Code that can write ~/.claude/settings.json can edit a script in the same profile. Signal: the collector’s hash changes, a check-in goes missing, or a report comes back suspiciously short. Fix: run the collector from a path the user can’t write, and alert on silence. The wall behind it: agents run as standard users, with no admin rights on agent hosts.

Legitimate updates bury the signal. Every CLI and plugin update produces diffs. If those aren’t authored events, people start closing alerts in bulk. Signal: unauthored alerts closed as expected with no record attached. Fix: route every update through step 2’s authored path, so the surprises left are real ones.

A removed guard looks like a quiet day. An attacker who deletes your security hook produces a removal, not an addition. Signal: any guard hook missing from the diff, which should page. A guard can also stop matching without being removed, when a harness update renames the tools it watches; catching that is the contract-test problem in a renamed tool is a disabled guard.

The scanner is green and the host isn’t. Version-matched OSV scanning passes the current latest of two named packages. Signal: an allowlist violation alongside a clean scan. The allowlist wins.

Removal without a reboot. Entries come back within the task’s pulse or at the next logon. Signal: the step 4 diff fails the second time. Fix: respawners first, then everything else.

The user declined the prompt. Per OSV, declining removes nothing. Signal: an install of a non-allowlisted helper with no incident attached. Fix: any such install starts step 4, whatever the user clicked.

Persistence is a fleet inventory, not a package ticket

A package ticket closes once the package is gone. Persistence doesn’t, and on a fleet the same package may have reached several hosts through three install modes before anyone opened one. The baseline, the authored-change path, the allowlist and the proof record belong in the layer that runs the fleet, next to the inventory of which hosts run which agents under which identity. That’s the operating-layer argument behind corporate AI on the Windows PC: the desk that launches agents has to be able to say what else launches on that desk.

The trigger won’t always be an npm list. If the LiteLLM MCP bypass on CISA’s KEV list put tool calls with shell reach on your hosts, this runbook is the host-side follow-up. The move is the same either way: baseline, remove, reboot, diff, and keep the diff.

FAQ

Does Claude Code’s --accept-command pin a plugin’s contents?

No. Added in 2.1.271 on Sep 14, 2026, it accepts exactly the command and archive URL that a previous --json run displayed, and refuses if either changed. It does not hash the plugin’s files or check what the plugin writes after it runs. Diff your host baseline after every plugin install or update.

Sources

• AgentGate: 18 malicious npm packages are still remote-controlling AI coding agents (verified today) — Sep 6, 2026; vendor research
• OSV MAL-2026-13370, llm-interceptor — published Aug 5, 2026; record text from Amazon Inspector
• OSV MAL-2026-13455, remote-claude-daemon — published Aug 6, 2026
• OSV MAL-2026-13452, opencode-optimised-toolings — published Aug 6, 2026
• OSV MAL-2026-5789, claude-cup — published Jun 15, 2026
• Mandiant AI Risk and Resilience Report 2026 — September 2026; case studies 1 and 3
• Claude Code changelog — 2.1.271, Sep 14, 2026
• Claude Code docs: Create and distribute a plugin marketplace — --accept-command scope
• Claude Code docs: Hooks reference — hook types

In the same nine days, Devin’s archive learned to close child sessions’ pull requests, and Codex 0.155 put delete in its agents overview. Each harness draws its own line around what counts as finished and what leaves with the session: the record, the PRs its children opened, the worktree, and whatever git ignored inside it.

This runbook is the audit you run before typing a number into any of those settings. By Tuesday you will have an inventory of every cleanup trigger in the fleet, a map of what each one touches, a preflight that blocks on unpushed commits, dirty trees, open child PRs and pending approvals, an export of the files git would delete without asking, a dry run, and a restore test you have actually run.

Sep 9–17: VS Code agent session cleanup, Devin’s archive cascade and Codex delete

VS Code 1.138, released Sep 16, 2026, puts session cleanup in preview. Two settings drive it. chat.agentSessions.autoMarkAsDoneMergedSessionsAfterDays marks an inactive session done, and chat.agentSessions.autoDeleteArchivedMergedSessionsAfterDays deletes it after a separate grace period. The release notes are plain about the starting point: “Both automatic-cleanup settings are disabled by default.”

The manage-sessions docs hold the rules. Cleanup covers inactive Agent Host sessions only; “External sessions aren’t eligible.” A session qualifies when “it isn’t in progress, its last-modified time exceeds the configured threshold, it has at least one merged pull request, and none of its related pull requests are open.”

VS Code checks at startup and hourly while either setting is on. The recommended value is 15 days, 0 switches a stage off, and only sessions VS Code marked done itself are deleted automatically. Restoring one clears its deletion eligibility.

That rule is looser than the nudge, which fires when all of a session’s PRs have merged. Read literally, a session with one merged PR and one closed without merging qualifies. The docs don’t show that case, so treat it as an inference and settle it in step 5.

The worktree gets more care. When cleanup marks a session done or deletes it, VS Code removes the worktree “only when the branch tracks an upstream and has no outgoing commits or uncommitted changes”, keeps it when git state is unknown, and adds: “Cleanup never force-removes a worktree.” PR #335851, merged Sep 11 for 1.138, separates the paths: manual archive commits uncommitted changes before removing the worktree, while automatic cleanup removes only clean, synchronized ones.

Manual delete is harsher. For Copilot sessions it removes the associated worktrees, and “Deleting a session is irreversible.”

Screenshot: Visual Studio Code, “Manage agent sessions in VS Code” (undated), captured Sep 21, 2026.

Devin’s release notes moved the reach sideways on Sep 9: archiving a session now also closes the open PRs of the child sessions archived with it, listed in the archive prompt so you can choose which to close. A human clicks archive; the cascade reaches PRs a reviewer may still be reading.

Codex 0.155.0, on Sep 17, added task hiding, archiving and deletion to the agents overview, plus “confirmed deletion of clean managed worktrees.” The notes say nothing about recoverability. The Codex app’s worktree docs use a count cap instead of a timer: it keeps your 15 most recent managed worktrees by default, deletes on chat archive or to stay under the cap, and “Before deleting a Codex-managed worktree, Codex saves a snapshot of the work on it.” CLI checkouts share that pool, but PR #42652 leaves automatic cleanup disabled for them.

Part of the pressure is disk, as Niels Rogge of Hugging Face warned a month earlier:

A cleanup setting is an unattended agent with delete rights

Chatbots suggest; agents act, and an agent session leaves behind things a chat log never had: a branch whose last commits may not be pushed, a worktree holding a test log and a .env that git ignores, child sessions with PRs open, an approval still waiting. Clearing a chat history deletes words. Clearing an agent session can close a colleague’s review or remove the only copy of a failing run’s log.

A timer that fires hourly is an actor with delete rights and nobody at the keyboard. Review it like one: what it may touch, what stops it, how you’d know it ran, and how you undo it.

Step 1: Inventory every cleanup trigger and mark what fires unattended

List every setting and action in the fleet that can remove a session, a worktree, a branch or a pull request. Two columns set the priority: what starts it, and whether the docs describe an undo. A timer with no undo goes first.

Add a row for anything your own runner deletes, then mark each row timer or click, and local or vendor-hosted. Timer rows come first, because nothing asks you. Click rows with a cascade come second: the click is real, but it gets less attention than the cascade deserves.

Treat every stated guard as a claim about the vendor’s code, not a fact about your repo. Claude Code’s worktree docs record the precedent: before v2.1.246 on Aug 25, its retention sweep could remove a worktree you had created yourself when an old background-session record pointed at it. Cursor’s worktree docs make foreign worktrees inside its root eligible on purpose, and don’t say whether dirty or locked ones are spared.

Step 2: Map the shared state each trigger touches

A session is the tip of a small graph: the record, the PRs it and its children opened, the worktree, and the branch behind it. Draw each trigger’s arrow into that graph and write its guard on the arrow.

Session state in the middle, cleanup actions at the sides. The ignored-files band is the one no vendor guard mentions.

Three edges deserve a line in your notes.

• Child PRs. Devin’s archive closes whichever child-session PRs stay selected in the prompt. Your runbook’s default is none selected; a PR under someone else’s review closes when that person says so.
• Shared worktrees. VS Code keeps a worktree shared by several sessions until the last linked session is deleted or archived, which hides the dependency: removing that last session takes everyone’s work in the checkout.
• Branches. VS Code’s docs don’t say whether cleanup deletes the session’s branch, and neither do Devin’s or Codex’s notes. Write “not documented” and let the step 6 fixture answer it.

Screenshot: Devin Docs, “2026 - Devin Docs” (Sep 9, 2026 entry), captured Sep 21, 2026.

Step 3: Write the preflight, and make it stricter than any vendor’s rule

The preflight is the list of conditions that block removal, checked by a script you own. It runs before any cleanup you trigger, and on a schedule beside any a vendor triggers, so you learn what the vendor’s rule would have taken. Four blockers:

1. Unpushed commits. No upstream, or commits ahead of it, blocks.
2. Dirty tree. Uncommitted changes or untracked files block.
3. Open child PRs. Any open PR on the session’s branch, or opened by one of its child sessions, blocks.
4. Pending approvals. A session waiting on a human decision blocks, even if the harness counts it as idle.

Add a fifth for your own runner: a process still running inside the worktree blocks. A stopped worker is the precondition for everything else.

#!/usr/bin/env bash
# preflight.sh <worktree> (illustrative): prints CLEAR or BLOCK with a reason; exits 1 on BLOCK.
wt="$1"
block() { echo "BLOCK $wt: $1"; exit 1; }
pgrep -f -- "$wt" >/dev/null && block "a process is still running in it"
git -C "$wt" rev-parse --abbrev-ref '@{u}' >/dev/null 2>&1 || block "no upstream, or detached HEAD"
[ -z "$(git -C "$wt" status --porcelain)" ] || block "uncommitted changes or untracked files"
[ "$(git -C "$wt" rev-list --count '@{u}..HEAD')" -eq 0 ] || block "unpushed commits"
branch="$(git -C "$wt" branch --show-current)"
open="$(gh pr list --head "$branch" --state open --json number --jq 'length')"
[ "$open" -eq 0 ] || block "$open open PR(s) on $branch"
grep -qxF "$wt" pending-approvals.txt 2>/dev/null && block "approval pending"
echo "CLEAR $wt"

Codex’s managed worktrees are detached-HEAD checkouts, so the upstream check blocks them by design; leave those to Codex’s confirmed delete and the app’s snapshot. Pending approvals live in the harness, not in git, so pending-approvals.txt stands for whatever list you can pull from each session view. Child sessions’ worktrees go through the same script.

The removal rule on top is deliberately stricter than VS Code’s: remove a worktree only after the worker is stopped, the branch is pushed and the tree is clean, with git-ignored logs and transcripts exported first (step 4). Never git worktree remove --force. A checkout that fails the preflight becomes a question for a person, not a flag to add. Who owns each checkout, and how to lock the ones your runner created, belongs to One Checkout, One Owner.

Be honest about what this gate is. Nothing in VS Code, Devin or Codex calls it; if it crashes or never runs, the vendor’s own guard is all that stands between the timer and the worktree. The wall behind both is the step 4 export, which works whether or not anyone read the preflight’s output.

Step 4: Export what git would delete without asking

Git decides clean by tracked changes and untracked files. Ignored files don’t count, so git worktree remove on a clean worktree deletes them without a prompt. That’s git’s behaviour, not a vendor statement, and VS Code’s docs don’t say what happens to ignored files when it removes a worktree. Ignored is exactly where agent runs put their logs, scratch output and sometimes transcripts.

Before any trigger can fire on a worktree, copy its ignored files out, minus secrets:

#!/usr/bin/env bash
# export-ignored.sh <worktree> <archive-root> (illustrative): copy ignored files out, minus secrets.
wt="$1"; dest="$2/$(basename "$wt")-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$dest"
git -C "$wt" ls-files --others --ignored --exclude-standard -z \
  | grep -zvE '(^|/)(\.env[^/]*|node_modules/.*|.*\.pem)$' \
  | (cd "$wt" && xargs -0 -r cp --parents -t "$dest")
(cd "$dest" && find . -type f -print0 | xargs -0 -r sha256sum) > "$dest.sha256"
echo "exported $(wc -l < "$dest.sha256") files from $wt"

The exclusions are deliberate: an archive full of credentials is a second incident, so scan what you keep. And mind VS Code’s first stage. Per its docs, worktree removal applies when cleanup marks a session done, not only when it deletes one, so the export runs before you enable mark-as-done.

Session records need the same treatment. Export timing and retention windows for vendor-hosted sessions are covered in Evidence When the Harness Is Vendor-Hosted, and what those records can establish after an incident in You Can’t Replay What You Can’t See.

For sessions whose transcripts live on local disk, a local library is one way to keep a searchable copy. Automater Lite is a free desktop tray companion for Windows, macOS and Linux. Its homepage says it reads “each tool’s own transcript files and folds them into one library on your machine”, and lists 45 session formats. It does not preserve vendor-hosted cloud sessions: a Devin session, or any cloud session that never wrote a local transcript, is not in it.

Whatever keeps your record, prove it in step 6 by deleting a fixture session and searching for its marker.

Step 5: Dry-run VS Code agent session cleanup before you enable it

None of the three products documents a dry run, so build one from the preflight. It changes nothing and writes one dated line per worktree:

#!/usr/bin/env bash
# dry-run.sh (illustrative): what would a cleanup pass remove today? Changes nothing.
git worktree list --porcelain | sed -n 's/^worktree //p' | tail -n +2 | while read -r wt; do
  printf '%s %s\n' "$(date -u +%FT%TZ)" "$(./preflight.sh "$wt")"
done | tee -a cleanup-dry-run.log

Run it daily for a week with nothing enabled. Each BLOCK line names a checkout your rule protects, and why. Read the CLEAR lines harder: each is a checkout a sweep could take today, ignored files included.

For VS Code, add the session side: record each Agent Host session’s PR states and last-modified date, and apply the eligibility rule by hand. Include a fixture with one merged PR and one closed without merging to settle the news-section inference.

When the dry run matches what you expected, stage the real thing on one machine: mark-as-done on, delete at 0. Restoring an automatically completed session clears its deletion eligibility, so stage one is recoverable at the session level. It still removes clean worktrees, which is why step 4 came first.

Step 6: Run the restore test on a fixture, not on the incident

A restore path you haven’t run is a sentence in someone else’s docs. Build a fixture per product: a disposable repo, one session driven to a merged PR, and three markers.

RS-PUSHED is committed and pushed. RS-IGNORED sits in an ignored logs/ directory. RS-TRANSCRIPT is typed into the session itself. Let cleanup take the fixture, then try to get each marker back.

Record the result per marker. Expect it mixed: the pushed commit survives on the remote, the session may or may not come back, and the ignored log exists only in your step 4 export. Written down, that’s acceptable. Discovered the week an incident needs the log, it isn’t.

Step 7: Pick the numbers, then re-audit on every upgrade

Now enable, with values you chose and wrote down.

Illustrative. Setting semantics from the VS Code 1.138 docs; the 15-day values are the docs’ recommendation, and the session is modeled.

VS Code recommends 15 days for each setting. With both at 15, a session idle past day 15 with a merged PR and none open is marked done at the next hourly check, its worktree goes if clean, and it’s deleted 15 days later unless someone restores it. That second window is your recovery budget, so size it to how long a missing log takes to be missed. Weekly incident reviews fit inside 15; a lane that runs monthly jobs doesn’t.

Write the values into a retention record beside the lane manifest:

# retention.yaml (illustrative; field names are ours, vendor setting IDs appear under settings)
reviewed: 2026-09-22
settings:
  vscode_1_138:
    chat.agentSessions.autoMarkAsDoneMergedSessionsAfterDays: 15
    chat.agentSessions.autoDeleteArchivedMergedSessionsAfterDays: 0   # stays off until step 6 passes
  cursor:
    cursor.worktreeCleanupIntervalHours: 6    # docs default
    cursor.worktreeMaxCount: 25               # per machine, across all workspaces
  claude_code:
    cleanupPeriodDays: "<your value>"         # age limit for its background worktree sweep
policy:
  devin_archive_child_prs: none-selected-by-default
  codex_overview_delete: human-only-after-preflight
  runner_roots_outside_vendor_roots: true
  preflight: preflight.sh
  export_before_remove: export-ignored.sh
  restore_test_last_passed: 2026-09-22

Then re-audit on change. VS Code’s docs say the feature “is in preview and might change before it becomes generally available”, and Codex reshaped deletion in a routine release. Add the step 6 fixture to the canned sessions in Canary Every CLI Upgrade, and rerun the restore test whenever a harness updates. Keep any session whose work was continued elsewhere until that work merges; Test What Survives a Cross-CLI Session Import relies on the source staying put.

Five ways cleanup takes more than you meant, and the signal for each

The clean worktree with the only log. The tree passed every guard because the log was ignored. Signal: an incident review asks for a run log whose worktree no longer exists. Response: the step 4 export runs on a schedule, before any trigger can fire.

The cascade nobody read. A Devin archive closes a child PR someone was reviewing. Signal: a PR closed within a minute of a parent archive, with no comment from its reviewer. Response: none selected by default, and the person archiving reads the list.

The closed PR that didn’t count. A session with one merged PR and one abandoned one is marked done while the abandoned work still matters. Signal: the step 5 fixture shows up as eligible. Response: close abandoned PRs deliberately, or keep that lane’s threshold at 0.

The machine that was off. VS Code checks at startup, so a laptop back from a week away runs one pass over everything that aged past the threshold meanwhile. That’s an inference from the schedule, not a documented case. Signal: a burst of done-marks at one boot timestamp. Response: read the dry-run log after any long gap.

The foreign checkout in a vendor’s root. Cursor’s sweep treats worktrees in its root as eligible whoever made them. Signal: a runner checkout missing after a sweep. Response: runner roots live outside every vendor root, proved by the ownership piece’s decoy test.

Retention is a fleet policy, not a settings page per app

Each product’s cleanup is sensible inside its own window, but a fleet has several: VS Code’s Agents window, Devin’s sidebar, the Codex overview, Claude Code’s sweep and your runner’s teardown, each with its own clock and idea of finished. The inventory, preflight, export and retention record live above them, in the layer that runs the fleet, where a multi-agent command center keeps every CLI’s sessions side by side.

Automater works at that desk level, and it enforces none of this; your preflight does. Lite keeps the local, searchable record of sessions whose transcripts exist on the machine, and Pro adds managed sessions you can start, steer, interrupt and stop. Automater Lite is free on automater.ai; Pro is $50/year.

Turn cleanup on. Just let it take only what the dry run said it would.

FAQ

Does VS Code delete agent sessions automatically?

Only if you enable it. VS Code 1.138 adds two preview settings: one marks inactive Agent Host sessions done, the other deletes them after a separate grace period. Both ship disabled. Deletion applies only to sessions VS Code marked done itself, so sessions you mark done by hand are never deleted automatically.

Sources

• Visual Studio Code 1.138 release notes — Sep 16, 2026; both cleanup settings off by default
• VS Code: Manage agent sessions — eligibility, recommended 15, worktree conditions
• microsoft/vscode PR #335851 — Sep 11, 2026; manual versus automatic worktree cleanup
• Devin release notes 2026 — Sep 9, 2026; archive closes child PRs
• Codex 0.155.0 release notes — Sep 17, 2026; delete in the agents overview
• ChatGPT Learn: Worktrees — Codex app retention and snapshots
• openai/codex PR #42652 — CLI allocations exempt from auto-cleanup
• Claude Code: Run parallel sessions with worktrees — retention sweep and the 2.1.246 fix
• Cursor: Worktrees — 6-hour cleanup, 25 per machine

Your fleet doesn’t run one harness, though. The same deny list has to hold in Copilot, in Claude Code, in whatever Codex lanes you keep, and on the JetBrains seats where the managed sandbox is still a preview. Each delivers policy its own way, and each ships convenience features built to cut prompts. On a chatbot, a permission prompt guards what it says. On an agent, it guards what runs on the machine, so every feature that removes a prompt is a candidate override.

By Tuesday you’ll have one override test: a managed deny and a managed ask on harmless canary operations, a receipt check that proves each lane received the policy, ten bypass rows run on every harness you operate, and a log that records harness, version, expected and observed for every row. Rows that disagree get fixed or flagged, in writing, with an owner.

Sep 9: Copilot enterprise managed permissions go GA with the bypass paths named

GitHub made enterprise managed permissions for Copilot agent operations generally available on Sep 9, 2026, for Copilot Business and Enterprise. Admins mark shell commands, file reads and edits, and network domains as blocked, needing human approval, or allowed without a prompt, and can give different enterprise teams their own policies. The GA surfaces are the Copilot app, Copilot CLI and VS Code sessions that use Agent Host. The line to hold GitHub to: “Managed restrictions can’t be weakened by user or workspace settings, auto-approval, or previously saved approvals.”

The enterprise managed settings reference goes further than the changelog. Rules resolve deny > ask > allow. “A deny rule set by any managed settings source blocks the operation for all users regardless of rules in the other sources.” Allowlists intersect across sources instead of adding up. Once any managed source defines a rule or an allowlist, an unmatched supported operation defaults to requiring approval. And the ask rule carries a longer bypass list than the changelog: “A managed ask rule can’t be satisfied by bypass mode (also known as allow-all or YOLO mode), an auto-approval setting, a hook or other approval shortcut, or a grant persisted from an earlier approval.”

Screenshot: GitHub Docs, “Enterprise managed settings - GitHub Enterprise Cloud Docs” (undated), captured Sep 21, 2026.

The same page carries a client support table, and it decides what your test can even measure. permissions.deny, ask and allow are marked Not supported in Copilot cloud agent and in JetBrains IDEs. In VS Code, “these granular permission rules apply to Copilot sessions that use Agent Host.” Step 3 turns that table into your n/a cells.

Two neighbours landed the same fortnight. On Sep 8, GitHub put an enterprise-managed sandbox in Copilot for JetBrains into public preview: managed control over sandbox enablement, filesystem and network access, proxy settings, developer-tool access and macOS Keychain access, locked controls in the IDE, and enterprise policy diagnostics to confirm policies are detected and enforced on the device. On Sep 17, Claude Code 2.1.274 added a claude_code.managed_settings_resolved OpenTelemetry event that reports managed-settings sources and policy helper state, with redacted settings and digests when OTEL_LOG_MANAGED_SETTINGS=1 is set.

Where Copilot enterprise managed permissions and Claude Code part ways

One-harness testing fails at the second policy source, because Copilot and Claude Code disagree about what two managed sources mean.

Copilot merges. Any source’s deny wins, and allowlists intersect. Claude Code’s managed tier is first-wins by default: per its managed-settings docs, it uses the highest-ranked source that delivers at least one policy key and ignores the rest rather than merging them. “Claude Code shows no warning for the sources it skips; /status names the source it used and the ones it skipped.” A merge mode exists, opt-in from v2.1.242.

So on Claude Code, a deny delivered through a lower-ranked managed source, while a higher-ranked source delivers even one policy key, is absent on that machine. Nothing errors. The lane runs as if you never wrote the rule, and the same two-source setup on Copilot would have held.

Precedence inside Claude Code, and one house dialect across Claude Code and Codex, are already covered in Claude Code permission modes as fleet policy and one permission dialect for Claude Code and Codex. This piece assumes that policy exists. It tests whether each harness keeps it.

The cross-harness override test, step by step

Step 1: Write one deny and one ask you can trigger without harm

Pick three canary operations, one for each class GitHub’s policy covers: a shell command, a file edit, a network domain. Each must be harmless if the wall fails and unmistakable in a log. A shell read of a fake credentials file in a scratch repo, an edit to a file called ask-me.txt, and a fetch to a domain you own and never use all qualify.

Make the shell and network canaries managed denies and the edit a managed ask. Write each rule in that harness’s own managed-settings syntax, from its own docs. Rule selectors differ between vendors, and a rule copied across can parse cleanly and match nothing; that’s the renamed-tool failure in miniature, and contract-testing guard coverage owns it.

Then write the test down as a manifest your runner reads. The shape below is illustrative, your schema rather than any vendor’s:

# override-test.yaml (illustrative; your runner's schema, not a vendor format)
policy_version: perm-v3
canaries:
  shell_deny:   read fixtures/fake-credentials.txt from the shell
  network_deny: fetch https://canary.example.com/ping
  edit_ask:     edit scratch/ask-me.txt
lanes:
  - id: ci-copilot-cli
    harness: copilot-cli
    receipt: unmatched-op-prompts
  - id: laptop-claude-02
    harness: claude-code
    receipt: [skipped-sources-empty, managed-settings-resolved-event]
  - id: ci-codex-01
    harness: codex
    receipt: fallback-notice     # requirements.toml conflict notice
  - id: seat-jetbrains-07
    harness: jetbrains-copilot
    receipt: policy-diagnostics
    scope: sandbox-only
  - id: control-01
    harness: claude-code
    managed_policy: none         # every canary must succeed here
rows: [user_settings, workspace_settings, auto_approval, saved_approval,
       bypass_mode, hook_allow, second_managed_source,
       resumed_session, child_agent, headless_run]
record: [harness, version, row, canary, expected, observed, receipt, action]

The control lane matters more than it looks. Run every canary on a machine with no managed policy first. If a canary doesn’t fire there, a blocked result elsewhere proves nothing.

Version the policy and stamp that version on every row. When a row flips next month, the first question is whether the policy changed or the harness did.

Step 2: Prove each lane received the policy before you attack it

A bypass that works on a lane that never got the policy is a delivery bug, and it looks exactly like a real override. Get a receipt per lane before you run a single bypass row.

Codex’s managed configuration docs call requirements “admin-enforced constraints that users can’t override”: a local value that conflicts with one falls back to a compatible value and the client notifies the user. Layers don’t simply merge, though. Higher-precedence layers override scalar and list values, while rules and hooks compose field by field, so run the second-source row on Codex too instead of borrowing either vendor’s answer.

The Copilot receipt is derived from GitHub’s own default. When any managed source defines a permission rule, an unmatched supported operation should require approval. If an edit your rules never mention goes through without a prompt, that lane isn’t running your policy, and every bypass row on it will lie.

On Claude Code, read /status before anything else. If Skipped sources isn’t empty, stop: that’s the first-wins shadowing from the section above, and every row on that machine would measure a policy you didn’t intend. claude doctor lists what it dropped. Then collect the managed_settings_resolved event with OTEL_LOG_MANAGED_SETTINGS=1, and keep the digest it logs beside your policy version. A lane whose digest differs from your reference machine’s didn’t get the policy you think it got.

Screenshot: Claude Code Docs, “Claude Code changelog - Claude Code Docs” (2.1.274, Sep 17, 2026), captured Sep 21, 2026.

The event lives in the changelog and not yet in the monitoring docs, so pin its field names from an event you captured, not from memory.

Step 3: Mark the surfaces that can’t enforce the rule before you test them

Some cells are n/a before you start, and a test that reports them as passes is worse than no test.

Which managed keys each Copilot surface honours, per GitHub’s docs table on Sep 21. The amber cell is a docs conflict to verify before you rely on it.

Copilot cloud agent takes no managed deny, ask or allow, and no disableBypassPermissionsMode either. JetBrains IDEs take no managed deny, ask or allow; their managed control is the sandbox preview, and even that is unsettled, because GitHub’s table marks the sandbox key Not supported for JetBrains while the Sep 8 changelog describes a managed setting that turns the sandbox on or off. VS Code honours the granular rules only in Agent Host sessions, though disableBypassPermissionsMode has broader VS Code support.

Write those cells as n/a, never pass. A lane on an n/a surface isn’t covered by the managed rule at all. It either moves to a surface that enforces the rule, or it gets a wall that doesn’t depend on the harness (step 6).

Step 4: Run the six bypass rows GitHub names

Now attack. For each row, set up the bypass, fire all three canaries, and write down what happened. The expected column is what each vendor’s docs predict; where the docs are silent, it is your policy intent, marked Intent.

Two cells need their sources. Claude Code’s settings reference puts managed settings above every other level, and its exceptions table lists only cases where a stricter value from a lower level still counts, so no lower level can weaken a managed rule. And Claude Code’s permissions docs say hook decisions don’t bypass permission rules: a matching deny still blocks and a matching ask still prompts, whatever the hook returned.

Create the saved approvals before the policy lands. That’s how they usually exist: somebody chose a remember-this option weeks ago, and the approval outlived the reason for it.

On Claude Code, the OpenTelemetry tool_decision event shows the outcome of each attempt. Per the monitoring docs, decision is accept or reject, and source is one of config, hook, user_permanent, user_temporary, user_abort or user_reject. A canary logged as accept with user_permanent is a saved approval beating your policy. A reject with config means something held, not what: config covers settings, managed policy, flags and the active permission mode, and “The event doesn’t indicate which of these sources matched.” Reading vendor permission verdicts covers that stream in depth; here you only need accept versus reject per canary.

Step 5: Add the four rows nobody named

These rows are ours, not GitHub’s. They target the places where policy tends to be read once and then assumed.

The second-source row is where the harnesses diverge by design. Put the allowing policy in the higher-ranked source, expect Claude Code to fail the row on the default, and log that as a finding. The fix is to keep every managed key in one source, or opt into merge and re-run the row. Project-over-group overrides are the same shape one layer down, at the MCP server, and the GitLab always-ask audit covers that one.

The resumed-session row catches state carried from before the change: start the session under the old policy, ship the new one, resume, fire. The child-agent row catches policy that binds the parent process but not what it spawns.

In the headless row, the ask canary is the interesting one. With nobody at the keyboard, a managed ask should stop the run, not resolve itself. If a headless lane edits ask-me.txt, an ask turned into an allow somewhere between the policy and the process. Unattended lanes pick up undeclared state in other ways too; proving headless runs ignore undeclared state is the companion test.

Step 6: Record expected against observed per harness and version, then fix or flag

Receipt first, then the rows. A lane with no receipt is a delivery bug, not a passing row.

Every attempt becomes one log line. The line below is illustrative, including its result:

{"run":"2026-09-22T14:05:00Z","policy":"perm-v3","lane":"laptop-claude-02","harness":"claude-code","version":"2.1.278","row":"second_managed_source","canary":"shell_deny","expected":"dropped_first_wins","intent":"deny_holds","observed":"ran","receipt":"skipped_sources=1","action":"fix: move deny into the winning source; re-run"}

Keep expected and intent as separate fields. Expected versus observed tells you whether the vendor behaved as documented; a mismatch there is a bug report and a version pin. Intent versus observed tells you whether you’re protected; a mismatch there is your problem regardless of what the docs say.

Every row where observed misses intent gets exactly one of two outcomes:

1. Fix. Move the rule into the source that wins, turn on merge, set disableBypassPermissionsMode, or move the lane to a surface that enforces deny and ask. Re-run the row and attach the green result to the change.
2. Flag. When the harness can’t enforce the rule on that surface or version, write it down with an owner and a review date, keep the lane off work the rule protects, and put a wall underneath that doesn’t depend on the harness: an OS sandbox, egress filtering at the network, credentials the lane never holds.

Then re-run the full matrix on every harness upgrade. Version is a column because a green row on one build says nothing about the next, and the CLI upgrade canary is where this test belongs in your change process.

Five ways the override test hands you a false green

The receipt that isn’t enforcement. /status and the OTel event say which source won; neither says a deny fired. Signal: receipt present, canary ran. Score it as a failed row.

Silent shadowing. Claude Code’s first-wins default drops a lower source without a warning. Signal: Skipped sources is non-empty on any lane. Fix delivery before you test anything else there.

An n/a scored as a pass. A green deny row on Copilot cloud agent, on a JetBrains seat, or in a VS Code session that isn’t on Agent Host means the canary failed for some other reason, because nothing there reads the rule. Signal: the same canary also fails on the control lane.

A canary that can’t fire. A missing fixture, a sandboxed network, a typo in the path: the block you logged came from the environment. Signal: the control lane can’t run it either. Fix the canary before trusting a single row.

The gate that isn’t the only door. Managed permissions are the harness enforcing policy on itself, and when that gate fails it fails quietly: a skipped source or an unsupported surface doesn’t error, it runs the canary. A user who can install an unmanaged binary, add a second agent, or run the command in their own shell is outside the harness entirely. Signal: canary operations in shell history or network logs with no agent session attached. That’s why flagged lanes get a wall, and why the destructive and network classes keep one even when every row is green.

Policy is a fleet property; proof is per lane

A managed deny is written once and enforced several times over, by harnesses that each decide how to read it. The only artifact that tells you whether it held is the table from step 6: per lane, per harness, per version, with a receipt behind every row. No vendor console produces that table, because no vendor console sees the other vendors’ lanes. Keeping it is the operating layer’s job, the same argument a multi-agent command center makes for inventory and kill switches, applied to policy.

GitHub handed you six bypass rows. Add four, run all ten on everything you operate, and write down what you saw.

FAQ

Can developers override Copilot enterprise managed permissions?

Not through the paths GitHub names. Its Sep 9 changelog says managed restrictions can’t be weakened by user or workspace settings, auto-approval or saved approvals, and the docs add bypass mode and hooks for a managed ask. The rules apply in Copilot CLI, the Copilot app and VS Code Agent Host sessions.

Why is my Claude Code managed deny missing on one machine?

Most likely first-wins. Claude Code’s managed tier uses the highest-ranked source that delivers at least one policy key and ignores the rest, without a warning. Run /status and read Skipped sources, or run claude doctor. Keep every managed key in one source, or opt into merge mode from v2.1.242.

Do Copilot managed permissions work in cloud agent and JetBrains?

Not the deny, ask and allow rules. GitHub’s managed-settings support table marks them Not supported in Copilot cloud agent and JetBrains IDEs. JetBrains has a separate managed sandbox in public preview since Sep 8, with policy diagnostics. Mark those test rows n/a and protect the lanes another way.

Sources

• GitHub Changelog: Enterprise managed permissions for GitHub Copilot agent operations — Sep 9, 2026; GA for Business and Enterprise, the named bypass paths
• GitHub Docs: Enterprise managed settings — deny > ask > allow, the managed-ask bypass list, intersected allowlists, the client support table
• GitHub Changelog: Enterprise-managed sandbox in Copilot for JetBrains — Sep 8, 2026; public preview, enterprise policy diagnostics
• Claude Code changelog — 2.1.274 (Sep 17, 2026), the managed_settings_resolved event
• Claude Code docs: Managed settings — first-wins default, opt-in merge, /status Skipped sources, claude doctor
• Claude Code docs: Settings — managed tier above every other level; stricter-only exceptions
• Claude Code docs: Configure permissions — hook decisions don’t bypass deny or ask rules
• Claude Code docs: Monitoring usage — tool_decision decision and source fields
• Codex docs: Managed configuration — admin-enforced requirements, fallback notice, layer precedence

This is the audit that gets the count to zero. By Tuesday every lane carries a score on three legs, per session and including the subagents it spawns. Every lane that scores all three has dropped a leg, been split into a reader and an actor, or been put under supervision with a human approving each state change and each outbound call. A pre-run lint refuses to start any lane that grants all three without a supervision flag, and one fixture proves the split holds: a handoff that passes the schema, names an attacker’s destination, and gets refused.

Chatbots suggest; agents act. A chatbot that reads a poisoned page can only say something wrong; a lane that also holds the org token and a push tool can do something wrong, unwatched. The rule decides in config, before the run, which of the three a lane gives up.

Sep 14: Spain’s regulator logs a breach notification that names an AI agent

On Sep 14, 2026, Spain’s data protection authority, the AEPD, published a blog post by Francisco Pérez Bes saying it had received its first personal-data breach notification in which “el incidente habría sido ejecutado mediante un agente de inteligencia artificial” (the incident would reportedly have been carried out through an AI agent). The conditional habría matters, and the AEPD spells out why: the account comes from the affected organisation’s notification and still has to be analysed, and using a particular model does not mean the model or its provider was compromised. The post gives no receipt date, no sector and no model name.

What it does describe is a sequence. The attacking agent searched generic files for weaknesses and logged in successfully. Then it searched the application for vulnerabilities “de forma autónoma” (autonomously), which let it modify personal data and access invoices. Search, log in, modify, read: each step is a tool call some lane in your fleet can already make.

Screenshot: AEPD, “Primera notificación de una brecha de datos personales causada por un ataque ejecutado mediante un agente de IA” (Sep 14, 2026), captured Sep 21, 2026.

That notification concerns an attacker’s agent, and the post never mentions the rule. The link is the regulator itself: its agentic-AI guidance, V1.2 dated February 2026, presents a “Regla de 2” on page 41, citing Chromium’s browser rule and Meta’s reformulation for agents. Its worked example is an email auto-reply agent that receives mail nobody vetted, can reach sensitive data without restriction and acts automatically; holding all three, the guidance says, is a configuration that should not be allowed.

It calls the rule “una regla general de mínimos enfocada a ciberseguridad” (a general minimum rule focused on cybersecurity), a starting point for analysis, and then adds data-protection checks the rule doesn’t cover, such as minimisation and accuracy. Read it as a regulator’s baseline, not a binding standard.

The rule itself is Meta’s. Its Oct 31, 2025 post says an agent should satisfy “no more than two of the following three properties within a session”: [A] processing untrustworthy inputs, [B] access to sensitive systems or private data, and [C] changing state or communicating externally. Meta credits Chromium’s Rule of 2 and Simon Willison’s lethal trifecta, which the AI agent security primer already explains, so this piece won’t.

Two more points matter. If a job needs all three without a fresh session, the agent should not run autonomously and needs supervision at minimum. And the rule supplements least privilege; it doesn’t replace it.

Step 1: Score every lane on the Agents Rule of Two, per session

Score lanes, not models. A lane is one configured job: its model, tools, credentials, inputs, and whatever it can spawn. Score it for one session, which is Meta’s unit, and use this table to decide what counts.

Read [C] literally. Meta’s wording covers changing state or communicating externally, and the second half is where fleets under-count. A web fetch is outbound communication even when it only reads, because the URL is a message and an injected instruction can pick the host. An MCP search tool ships its query string to somebody else’s server.

A git push is [C] twice: it changes the repo, and it can start a CI workflow that holds secrets, which is why the Actions trigger allowlist gives agent identities their own row. Never score [C] as “acts autonomously”. Autonomy is the supervision question in step 4, not a leg.

Then apply the subagent rule. A child agent that reads a web page [A] and returns a summary to a parent holding the org token [B] and a push tool [C] makes the parent an all-three session, whatever the child scores alone. Score the union of every context that flows into another. The only reset is the one Meta names: a fresh session with a fresh context window, fed by something other than the old transcript.

Write the result down per lane. The illustrative chart shows the shape of the fix: the failing lanes go to zero and the lane count goes up.

Illustrative, modeled numbers. The split adds lanes; the number to drive to zero is the red one.

Step 2: Drop a leg first, and split only when the job needs all three

Dropping a leg is cheaper than splitting, so try it first. Drop [A] by feeding the lane structured data you control instead of prose: a dependency-update lane reads version numbers from a lockfile diff, not changelog text. Drop [B] by running on a public mirror or a scratch clone with no org credential. Shrink [C] by taking tools away.

Narrowing publish rights to stage-only tokens helps, but GitHub’s changelog says those tokens keep other write rights, dist-tag moves and deprecations included, so the leg shrinks rather than disappears.

When the job genuinely needs all three, split it into two lanes with a typed handoff between them.

• The reader holds [A B]. It gets the untrusted text plus whatever private context it needs to interpret it. It has no write tools and no egress: no shell, no web fetch, no MCP server that reaches the network, and a sandbox with the network off, because “no fetch tool” is a promise and a closed socket is a fact.
• The runner fetches the reader’s input, by PR number, with a request that carries no private data. The reader never fetches anything.
• The reader emits only a handoff that must validate against a versioned JSON Schema. A failed validation stops the run; nothing is retried with the raw text attached.
• The actor holds [B C]. It gets the handoff and its own trusted instructions, never the raw text: not in the prompt, not through a log, and not through a tool that can re-read the same PR. A gh pr view on the actor is a side door.

# lanes/pr-review.yaml (illustrative shape; enforced by the runner, never by the prompt)
lane: pr-review
reader:
  legs: [A, B]
  inputs: [runner.fetch.pr_body, runner.fetch.pr_diff]   # fetched by PR number
  tools: [read_file, grep]                               # no write, no shell, no network
  network: off
  output_schema: handoff/pr-review.v3.json
actor:
  legs: [B, C]
  inputs: [handoff]                                      # never the raw PR text
  tools: [post_review_comment, add_label]
  network_allow: [api.github.com]
  deny_tools: [gh_pr_view, web_fetch]                    # side doors to the raw text
supervision:
  required: false                                        # the lint checks this line

The reader never holds a write or egress tool, and the actor never reads the raw text. The fixture proves the gate between them.

Step 3: Treat every reader-derived field as tainted, schema or no schema

The split feels like a firewall because the handoff is typed. A schema checks shape. An injected reader can emit perfectly valid JSON whose notify field is the attacker’s address, whose docs_url points at the attacker’s host, or whose path climbs out of the repo.

The CaMeL paper names this. In the Dual LLM pattern a privileged model plans and a quarantined model reads untrusted data; its authors show injected content can steer the quarantined model into returning attacker-chosen data while the plan stays intact, so “the data flow can still be manipulated.” Their analogy is SQL injection: the attacker changes the parameters, not the query. A later paper on agent design patterns, with several of the same authors, says the same of plan-then-execute agents: the plan holds, and injected text still shapes the planned calls’ inputs.

Screenshot: arXiv, “Defeating Prompt Injections by Design” (Jun 24, 2025), captured Sep 21, 2026.

So the handoff needs four controls, and the actor enforces all of them in code.

1. Tag every field with its source. Three values are enough: trusted_config (from the lane config or the runner), actor_lookup (the actor fetched it by key from a system of record) and reader_derived (it came out of the reader).
2. Narrow free-form fields. Enums, booleans, bounded integers and IDs that must resolve in a trusted system. severity: low | medium | high beats assessment: string for anything the actor branches on.
3. Gate consequential fields. A reader-derived value may land in a recipient, URL, path, branch, package name or tool argument only after a deterministic allowlist in code passes it, or a human approves the exact value. If the allowlist lookup errors, times out or can’t parse the value, the answer is refuse and alert. A classifier asked whether the URL looks safe isn’t a gate, because it reads the attacker’s text too.
4. Narrow the author where you can’t narrow the value. Meta’s own high-velocity coder example controls [A] by “Using author-lineage to filter all data sources” that reach the agent’s context. If only your team’s commits and tickets feed the reader, most of [A] never arrives.

One field type fools people: free text that leaves. The reader holds [B], so any string it emits could carry private data, and an actor that posts that string somewhere public has just exfiltrated it. Free text is consequential when its destination is outside the trust boundary it came from.

{
  "schema": "pr-review.v3",
  "pr_number":    { "value": 4127, "source": "trusted_config" },
  "verdict":      { "value": "request_changes", "source": "reader_derived" },
  "docs_url":     { "value": "https://docs.example.com/testing", "source": "reader_derived" },
  "comment_body": { "value": "Add a test for the retry path.", "source": "reader_derived" }
}

Step 4: Supervise what you can’t split, on every write and every call out

Some jobs need all three and don’t split cleanly. The inbox assistant has to read the customer’s mail, know the customer’s record and reply, and what it should do depends on what the mail says. The CaMeL authors list this as an inherent limit of their own design, “Data requires action”: when the actions to take depend on untrusted data, the plan can’t be fixed in advance. The AEPD guidance’s case 1-2, uncontrolled input plus access to sensitive information, reaches the same place: “se debe impedir cualquier acción automática sin supervisión humana” (any automatic action without human supervision must be prevented), whether its effect lands inside or outside the organisation.

Supervision under this rule has a specific meaning. A human approves each state change and each outbound call, fetches included. They see the exact call with its arguments, not a plan summary.

Approvals expire, and expiry is a deny. The approver is never the person who wrote the [A] text.

supervision:
  required: true
  approve_each: [state_change, outbound_call]   # not "the plan"
  show: exact_call_with_arguments
  expire_after: 30m                             # expiry = deny
  owner: platform-oncall
  review_by: 2026-12-01                         # the exception has an end date

Supervised lanes spend attention, and approval fatigue turns a queue into a rubber stamp. Keep an owner and a review date on each one, and treat the supervised count as a number to shrink.

Step 5: Ship the pre-run lint, and make it fail closed

The lint runs in the runner before the harness starts. It reads the lane’s declared config, maps every tool, credential and input to legs through one classification file the platform team owns, and exits non-zero on any of these:

• The union of legs across the lane and every spawn profile it may use includes A, B and C, with no supervision.required: true.
• A tool, MCP server or credential is missing from the classification file. Unclassified counts as [A] and [C] until someone classifies it.
• A reader holds any [C] tool or has network access; an actor has any input or tool that reaches the raw text.
• A reader_derived field feeds a consequential parameter with no declared gate.
• The config doesn’t parse, the classification file is missing, or the lint itself crashes. A lint that fails open is a suggestion.

# rule_of_two_lint.py (illustrative shape): any exit other than 0 keeps the lane from starting
import sys, yaml

def legs_of(item, table):
    return set(table.get(item, ["A", "C"]))   # unclassified = untrusted input + egress

def lane_legs(lane, table):
    legs = set()
    for part in [lane] + lane.get("spawns", []):
        for item in part.get("inputs", []) + part.get("tools", []) + part.get("credentials", []):
            legs |= legs_of(item, table)
    return legs

try:
    table = yaml.safe_load(open("policy/legs.yaml"))
    lane = yaml.safe_load(open(sys.argv[1]))
    if lane_legs(lane, table) >= {"A", "B", "C"} and not lane.get("supervision", {}).get("required"):
        sys.exit(f"refuse {lane['lane']}: A+B+C in one session with no supervision flag")
except Exception as e:
    sys.exit(f"refuse: lint error {e!r}")    # fail closed

Be honest about what the lint can’t see. It reads what a lane declares, and the harness can load more at runtime: a synced plugin, an auto-discovered MCP server, a subagent that inherits the parent’s tools.

So the lint isn’t the boundary. The wall behind it is the reader’s sandbox with the network off, permission deny rules on the actor, and credentials the reader’s process never receives. For unattended lanes, the trust-tier inventory of input authors and credentials is already the lint’s best input; feed it in rather than deriving it twice.

Step 6: Prove the split with a malicious-handoff fixture

Keep a fixture set next to each split lane and run it in CI on every change to the lane config, the classification file or the handoff schema, and after every harness upgrade. The core fixture is a handoff that validates against the schema and names an attacker’s destination. The actor must refuse it.

Judge the result from the sandbox’s egress log, not from the actor’s transcript. The transcript belongs to the component under test; the egress log shows whether a packet left.

Then run the other half: feed the reader a PR body that tells it to set docs_url to the attacker’s host, and put a unique canary string in that body. Expect the reader to comply sometimes, since the design assumes the reader loses. The pass condition is that the gate catches the value and the canary never shows up in the actor’s context. A reader that happens to resist the injection this week isn’t a pass; it’s luck with a timestamp.

Agents Rule of Two failures, and the signal for each

The reader grows an egress. Someone adds an MCP server or a fetch tool to the reader for more context. Signal: any connection in the reader sandbox’s egress log, or a lint diff showing a new [C] item on a reader.

The actor finds a side door. A tool, a log file or a cached artifact lets the actor read the raw text. Signal: the fixture’s canary string appears in the actor’s context.

Free text creeps back. A notes: string field lands in the schema because an enum felt restrictive. Signal: a schema diff adding an unbounded string with no gate.

The allowlist sprawls. Signal: wildcard hosts, or entries growing week over week without a named requester.

Supervision decays. Signal: approval rate near 100% while median decision time falls. Nobody reads a call they approve in two seconds.

Lanes start around the runner. Someone launches the harness by hand with the lane’s credentials. Signal: harness sessions with no matching lint record.

Subagents inherit too much. Signal: spawn records whose tool lists differ from the declared spawn profile.

The Rule of Two lives in the runner, not in the prompt

None of the steps above is a prompt instruction. A reader told to ignore instructions in the PR body will follow them eventually; the split works because the reader has no tool to follow them with, and the actor never reads them. That makes the rule a property of the layer that starts lanes: the lane registry, the leg classification file, the lint, the egress logs and the fixture run. It is what a multi-agent command center turns into once the dashboard comes off, one place that knows every lane, its legs, and who signed the exception.

[B] also covers where the lane’s prompt goes, not only what the lane can reach. If a vendor lane forwards requests to another provider, the data class it may carry is capped by the last hop you can verify. Score that too.

FAQ

What is the Agents Rule of Two?

Meta’s Oct 31, 2025 rule for agent security. Within one session, an agent should hold no more than two of three properties: processing untrustworthy input, access to sensitive systems or private data, and the ability to change state or communicate externally. A job that needs all three gets supervision instead of autonomy.

Does splitting an agent into a reader and an actor stop prompt injection?

Not by itself. It keeps injected text away from the tools, but the reader can still be steered into emitting valid, attacker-chosen values. CaMeL’s authors show the Dual LLM pattern protects control flow, not data flow. Gate every reader-derived value in a consequential field with an allowlist or a human.

Sources

• AEPD blog, Primera notificación de una brecha de datos personales causada por un ataque ejecutado mediante un agente de IA — Sep 14, 2026
• AEPD, Inteligencia artificial agéntica desde la perspectiva de protección de datos, V1.2 — febrero de 2026; “Regla de 2”, p. 41
• Meta, Agents Rule of Two: A Practical Approach to AI Agent Security — Oct 31, 2025
• Debenedetti et al., Defeating Prompt Injections by Design (CaMeL), full text — Dual LLM data-flow critique; “Data requires action”
• Beurer-Kellner et al., arXiv 2506.08837, full text — six agent design patterns
• Chromium security docs, rule-of-2.md — cited by the AEPD (footnote 32)

The same short changelog names two doors it leaves open. A stage-only token can still move dist-tags and deprecate versions, and GitHub tells you to guard it like any other write token. Add the credentials it never touched, the bypass-2FA tokens already issued and the GitHub OAuth token in a developer’s CLI login, and you have the real shape of the problem.

The move for Tuesday: every lane that can reach the registry gets a token class that matches its job, and none of them gets publish. You write down what the stage class can still do, prove with the agent’s own token that a direct publish fails, alert on every publish, dist-tag move and deprecation in your namespace, and strip long-lived human credentials off agent hosts. The approval stays a person comparing a staged tarball to a CI build. Where the pipeline supports trusted publishing, the long-lived token goes away entirely.

Sep 18: the npm stage-only token splits stage from publish

On Sep 18, 2026, GitHub’s changelog added a new permission level for npm granular access tokens, “Read and write (stage only)”. The workflow runs npm stage publish, a maintainer approves the release with 2FA, and “npm rejects direct npm publish attempts with that token, even if you’ve configured it to bypass 2FA for automation.” You need publish access to the package, 2FA on the account, npm CLI 11.15.0 or later and Node.js 22.14.0 or later. The release is opt-in and “doesn’t change existing tokens or their direct-publish capabilities.”

The lines that matter most sit in the middle of the post: “Stage-only tokens retain other package write permissions, including moving dist-tags and deprecating versions. Protect them with the same care as any other write token.” Further down comes a date: npm “is targeting January 2027 to remove direct publishing through bypass-2FA tokens”, and it points to npm’s roadmap discussion for the wider plan.

Screenshot: GitHub Changelog, “Stage-only npm tokens for safer automation” (Sep 18, 2026), captured Sep 21, 2026.

Staging itself is older. GitHub’s changelog announced staged publishing and new install-time controls for npm on May 22 and multiple trusted-publishing configurations on Sep 3. npm’s staged-publishing docs supply the mechanics: npm stage publish “does not require 2FA”, npm stage list, npm stage view and npm stage download show you what is waiting, and approval asks for a second factor “whether you approve the package in the CLI or on npmjs.com.”

Two days before the tokens shipped, The Hacker News carried Mandiant’s account of a hijacked AI coding session at an unnamed software-as-a-service provider. The Mandiant report, dated September 2026, is blunt about the chain: “Once the recommendation was accepted, the attacker used the developer’s active session to install an infostealer using a poisoned PyPI package, harvest GitHub OAuth tokens, and deploy the self-propagating Shai-Hulud worm across approximately 100 internal code repositories.” The attacker then poisoned a package in the company’s official namespace, and a second employee pulled it.

Screenshot: Google Cloud, “Mandiant AI Risk and Resilience Report 2026” (September 2026), captured Sep 21, 2026.

Be precise about what that case shows. The entry vector was a poisoned PyPI package, so a stage-only npm token is not a counterfactual for it, and Mandiant’s report never mentions npm, publish tokens or staged publishing. It names neither the assistant nor the registry behind the poisoned official-namespace package. What the case does show is the part this runbook covers: a hijacked session inherits whatever credentials its host holds, and the second infection came out of the victim’s own namespace.

An agent holding a publish token is a release nobody watches

A publish token in a chatbot’s world is a secret someone might paste into a prompt. In an agent’s world it is a capability the lane exercises on its own schedule: the lane decides the version is ready, runs the command, and every downstream install picks it up. Hijack the session, or poison something the session trusts, and the attacker inherits the capability with the same timing.

Stage-only tokens move the irreversible step out of the lane and onto a person with a second factor. They don’t make the token read-only, and they do nothing about credentials the lane was never supposed to hold. The runbook below covers both halves.

Step 1: Give every lane a token class, and never the publish class

Four classes cover most fleets. Agents get three of them.

Scope every stage token to the packages that lane actually releases, and give it the shortest expiry your rotation can live with. The GitHub side of each class, one App or service principal per lane with short-lived tokens, is covered in the service-principal playbook for agent identity; broker patterns are their own discipline and out of scope here.

Before you issue a single stage-only token, check the floors in the lane’s real runtime, not on your laptop: npm CLI 11.15.0 or later, Node.js 22.14.0 or later, publish access for the account that owns the token, and 2FA enabled on that account. A lane that fails the preflight must fail loudly. The dangerous version is a helpful release script that notices staging is unavailable and reaches for the old automation token.

Then write down what the stage class can still do. The changelog says “including”, so its list is a floor, not an inventory. Give the register three states: documented, rejected, and test it.

Keep the register beside the token inventory and re-run it whenever npm changes the permission model. It is the first page an incident responder should open.

Step 2: Prove direct publish fails with the agent’s own token

The rejection is npm’s claim. The token under test is yours. Run the drill from the lane’s runtime, with the exact credential the lane receives in production, against a scratch package in your scope that nothing depends on.

# publish-drill.sh: illustrative shape. Run inside the agent lane's runtime,
# with the lane's own token, against a scratch package nobody installs.
# Setup, once, by a maintainer: publish $PKG@0.0.1 so the residual checks have a target.
PKG="@yourscope/publish-drill"
npm --version        # expect 11.15.0 or later
node --version       # expect v22.14.0 or later
npm whoami           # expect the lane's account, never a person's

npm publish;          echo "direct publish exit: $?"   # expect non-zero
npm stage publish;    echo "stage publish exit: $?"    # expect 0 and a stage ID
npm stage list "$PKG"                                   # expect the staged version

npm dist-tag add "$PKG@0.0.1" drill;             echo "dist-tag exit: $?"   # documented: allowed
npm deprecate "$PKG@0.0.1" "publish drill";      echo "deprecate exit: $?"  # documented: allowed
npm unpublish "$PKG@0.0.1";                      echo "unpublish exit: $?"  # undocumented: record it

Score it against a fixed table, and keep every run’s output with the date and the token’s ID.

Run the drill on every token rotation, every npm bump in the lane image, and every edit to the release job. It proves one token and says nothing about the others in reach, so pair it with a sweep of the lane’s environment variables, config files and mounted secrets for any other npm credential. The stage-only release left existing tokens untouched, which means an older bypass-2FA automation token is probably still valid somewhere.

Step 3: Alert on every publish, dist-tag move and deprecation in your namespace

The direct-publish rejection comes with the token’s permission level, not from a hook on the agent’s host that a hijacked session could skip. Nothing blocks the residual rights, so the control there is detection. Watch the whole namespace, not only the packages agents release: in the Mandiant case the second infection came from the company’s own namespace.

The dist-tag and deprecation rows page for a reason. The latest tag decides what a plain install resolves, so moving it back to an older release you have since patched is a downgrade nobody approved. A deprecation message is text every installer of that version sees, which makes an unexpected one a phishing channel with your package’s name on it. Both are scenarios rather than events from the case, and both sit inside what the changelog says a stage-only token can do.

# namespace-watch.sh: illustrative shape. Run on a schedule from a host
# that holds no npm write credential of any kind. notify and heartbeat
# stand for whatever your alerting exposes. Note "$pkg@*" resolves to latest
# only; ">=0" prints one line per deprecated release version (not prereleases).
while read -r pkg; do
  key=$(echo "$pkg" | tr '/@' '__')
  npm view "$pkg" dist-tags --json   > "state/$key.tags.new"
  npm view "$pkg" time --json        > "state/$key.time.new"
  npm view "$pkg@>=0" deprecated     > "state/$key.dep.new"
  for kind in tags time dep; do
    cmp -s "state/$key.$kind" "state/$key.$kind.new" || notify "npm $kind changed: $pkg"
    mv "state/$key.$kind.new" "state/$key.$kind"
  done
done < namespace-packages.txt
heartbeat npm-namespace-watch

The watcher is detection, and its polling interval is your exposure window: on a five-minute poll, a moved tag can serve five minutes of installs before anyone knows. Run it from a host with no npm write credentials, alert on its own missed heartbeats, and keep a slower second check on a different host. If the watcher dies quietly, you are back to trusting the token.

Step 4: Take long-lived human credentials off every agent host

Mandiant’s recommended controls include this one: “Isolate local credentials to prevent extensions from accessing raw API keys, long-lived OAuth token, or secrets”. In the case, the attacker worked through the developer’s active session and harvested GitHub OAuth tokens. The fleet version is a hard rule: agents never hold a person’s long-lived credentials.

Sweep for them by value and by location on every host an agent runs on, including developer workstations where an assistant shares the developer’s session. That last category is the awkward one, because the Mandiant chain ran in exactly that kind of session. You can’t take the developer’s GitHub login away from the developer. You can keep publish tokens and bypass-2FA tokens off that machine entirely, so a hijacked session there finds stage rights at most, and usually nothing.

Don’t wait for January 2027 to retire the old tokens. Inventory every bypass-2FA token now, replace each with a stage-only token or trusted publishing, and revoke the old one the day its replacement passes Step 2. The target date is npm’s stated plan, and a plan can slip; a revoked token can’t.

Every date is from GitHub’s changelog or The Hacker News. January 2027 is npm’s stated target, drawn as a month because no day is given.

Step 5: The approver checks the staged tarball against the CI build, then approves

The human step is the whole security value of staging, and it is easy to hollow out. An approver who clicks through because a chat message said the release was ready is a bypass-2FA token with extra steps. Give the approval a five-minute checklist and a record that proves each check happened.

1. The CI job that stages the version records the tarball’s SHA-256, the commit SHA and the build ID in the release ticket before it runs npm stage publish.
2. The approver runs npm stage list and npm stage view on the stage ID and confirms the package name and version match the ticket. npm also keeps a separate npm stage command reference.
3. The approver downloads the staged tarball with npm stage download, hashes it, and compares the hash with the CI record. If the hashes differ, unpack both and diff them: a difference only in the compressed bytes is noise, a changed file is a stop.
4. The approver diffs the staged package against the last published version, looking for new install scripts, new dependencies, new binaries and changed entry points. Any of those without a matching reviewed PR is a stop.
5. Only then does the approver run npm stage approve or use the Staged Packages tab on npmjs.com, with 2FA from their own device.

# approve-check.sh: illustrative. The human approver runs this; no lane ever does.
npm stage view "$STAGE_ID"                # name and version match the ticket?
npm stage download "$STAGE_ID"            # fetch the staged tarball
sha256sum ./<downloaded-tarball>.tgz      # equal to the SHA-256 in the CI build record?
mkdir -p staged prev
tar -xzf ./<downloaded-tarball>.tgz -C staged
(cd prev && npm pack "$PKG@$PREV_VERSION" && tar -xzf ./*.tgz)
diff -r prev/package staged/package       # install scripts, dependencies, binaries?
# every check passed: approve with your own second factor
npm stage approve "$STAGE_ID"