Here's the short version. Claude Code v2.1.225 (August 8, 2026) shipped two things that only matter once more than one person — or one unattended agent — is running the tool. Neither is flashy. Both fix a failure that used to arrive with no useful information attached.

One: when a gateway rejects a request because you've hit a spend cap, the limit-reached message now names the cap, its reset time, and the operator's message — instead of a bare error the developer can't act on. Two: claude agents, the subagent and background-agent runner, now prompts for workspace trust in an untrusted directory, the same "do you trust this folder?" gate the interactive claude command has always shown. Until this build, that gate only guarded the interactive CLI, so an agent could start reading a cloned repo's CLAUDE.md and settings before you'd approved the directory.

If you run Claude Code solo, in repos you already trust, on a subscription with no gateway in front of it, you can stop here — you won't notice either change. If you run it across a team, or point background agents at code they didn't write, read on: these are the two walls your people were hitting blind.

Wall 1 — the spend cap that wouldn't tell you anything#

Teams put Claude Code behind an LLM gateway — LiteLLM, MLflow AI Gateway, an internal proxy, or a managed apps gateway — so that every request is attributed to a person or a key, token cost is recorded, and a budget can be enforced per user or per workspace. You wire it up by pointing the client at the gateway:

export ANTHROPIC_BASE_URL="https://llm-gateway.yourco.internal"
export ANTHROPIC_AUTH_TOKEN="sk-user-nadia"   # a per-person gateway key, not a raw provider key

The cap lives at the gateway, not in Claude Code. On the gateway side an operator sets a budget — in LiteLLM, for example, a key carries a max_budget and a budget_duration, and the proxy rejects requests once the budget is spent:

{
  "key": "sk-user-nadia",
  "max_budget": 200,
  "budget_duration": "30d",
  "metadata": { "team": "growth", "owner": "nadia@yourco.com" }
}

That part already worked. The problem was the other end. When the budget was exhausted, the gateway returned a rejection, and before 2.1.225 Claude Code surfaced whatever generic error came back — an opaque 429, a wall of nothing. The developer at the keyboard didn't know which cap they'd hit, when it resets, or who could raise it. So they filed a ticket, or pinged the admin, or just assumed the tool was broken.

v2.1.225 changes the client side: the limit-reached message now names the cap, its reset time, and the operator's message. The wall becomes self-service — the developer reads "monthly spend cap reached, resets Sep 1, ask #ai-platform to raise it" and acts on it instead of guessing.

The one requirement worth reading twice: the changelog says this requires the gateway on 2.1.225. The cap name, the reset time, and the operator note have to come from the gateway — the client can't invent them. So 2.1.225 renders those fields only when the gateway emits the limit metadata in the structured shape the new client reads. A gateway that returns only a plain 429 still stops the request; the developer just gets the old blank wall. To get the labelled message, the gateway has to report the limit in the agreed form. Confirm your gateway does before you promise the team a nicer error.

This is the operator-side twin of the cost-attribution work founders have been doing all summer — charging agent cost per task, not per call is how you know which work spent the budget; a labelled spend cap is how the person who hit it finds out at the moment it happens. If you're standing up spend governance from scratch, the Rippling AI-spend console lesson is the cautionary version of what an unlabelled wall costs a team.

Wall 2 — the untrusted repo an agent read before you trusted it#

Claude Code's workspace-trust prompt exists for one reason: a repository can steer the tool through files it controls. A malicious CLAUDE.md full of instructions, a project .claude/settings.json, a hook that runs on session start — all of it is content the tool would otherwise pick up the moment it opens the directory. So the interactive claude command asks "do you trust this folder?" on first run in a new directory, and holds that project-controlled configuration until you say yes.

claude agents — the path that spawns subagents and runs background agents — didn't ask. That's the asymmetry 2.1.225 closes. Before this build, you could point the agent runner at a freshly cloned repo, or a directory an upstream agent had just generated, and it would start in that directory and begin honoring the directory's own instructions without the trust check the interactive CLI always ran. The gate that protected the human at the keyboard didn't protect the agent running while the human was away.

Now claude agents shows the same trust prompt for untrusted directories, "matching the behavior of claude." The agent holds the untrusted directory's CLAUDE.md, settings, and hooks until the directory is trusted — same rule, now on both paths.

Why this matters more for agents than for humans: the interactive user is there, reading, able to notice a suspicious instruction. A background agent isn't. It's exactly the surface a supply-chain attack aims at — the same class of exposure as the ChainDrop npm worm that stole coding-agent credentials and the Amazon Q folder-trust RCE. Trust-gating the agent runner doesn't make an untrusted repo safe to execute — it makes the tool stop treating a cloned directory's instructions as your own before you've said so.

One caution on the other side. Because the gate now fires on claude agents, an unattended runner (a systemd unit, a CI job) will hit it. Resist the urge to disable trust wholesale for a runner that executes cloned code — that reopens precisely the hole this build closed. Trust the root workspace once so child workspaces inherit it, or run non-interactively where trust is granted by your provisioning rather than bypassed per repo. The right posture is the one the container-is-not-a-sandbox and secrets-management-for-ai-agents pieces argue for: bound what the agent can reach, don't blanket-trust what it reads.

What to actually do this week#

Two changelog lines, two walls that used to fail as a mystery, now labelled. That's the whole story — and on a team, labelled walls are the difference between a ticket and a shrug. This sits alongside the same build's sandbox credential-masking work: both are the unglamorous governance layer that lets an agent run without a human watching every request.