Claude Code 2.1.284 and 2.1.285 as a governance checklist for teams

The interesting line in the 2.1.284 release notes is not the new default model. It's the gateway spend limits, now visible with amounts in /usage. Cost controls used to be something you bolted on with a spreadsheet and a Slack reminder. Now there is a number inside the tool itself, and that changes what a sensible team setup looks like.

The two releases (28 and 29 September) bundle more than governance: Sonnet 5.5 as the default Sonnet model, a "Yes, but ask again next time" option in auto mode, /mcp reconnect all, claude --desktop, tooling for plugin configuration, the CLAUDE_CODE_DISABLE_WEB_FETCH environment variable, and fixes for session management and artifact publishing. I've read the notes, not stress-tested every item, so what follows is a way of stacking them, with my doubts marked.

A silent default is a pricing change

Start with the model default, because it's the control that moves your bill without anybody touching a config file. If your developers run whatever Sonnet the tool picks, then a release that bumps the default to Sonnet 5.5 has just changed your cost per session and your behaviour profile on the same afternoon. Maybe for the better. Nobody decided it, though.

For a team of any size I'd pin the model in managed settings and upgrade on purpose, after a day of comparing real tasks. It's boring advice. It is also the one that keeps a Tuesday release from becoming a Wednesday finance question. If you run a restricted or self-hosted setup, the pinning logic is the same, and I went through the policy side of that in the restricted mode piece.

What a hard ceiling actually buys you

Now the spend limit. The reason I like a limit enforced at a gateway, rather than a dashboard somebody checks on Mondays, is that it doesn't depend on the developer's laptop behaving. A runaway loop hits a wall at the proxy.

Here's the arithmetic that convinced me. Say an unattended agent burns 15 dollars an hour (a made-up figure, substitute your own from /usage). A loop that starts Friday at 18:00 and nobody notices until Monday 08:00 has run for 62 hours: 15 times 62 is 930 dollars, for one stuck session. Put a 50 dollar daily limit on that key and the same weekend costs at most 150. You haven't prevented the loop, you've capped the damage at something you can explain.

Two things I could not confirm from the notes. First, what the limit is scoped to: per user, per key, per team. That matters a lot, because a shared team key with one limit means one noisy developer blocks everybody else. Second, what the experience is when the limit trips mid-task. A hard stop during a long refactor can leave a branch half-edited, which is its own kind of cost. For capacity thinking over a longer horizon, the weekly limits planning piece is the companion to this one.

A spend limit does not stop a bad loop, it decides how much the loop is allowed to cost you.

Egress and approvals: smaller knobs, real effect

CLAUDE_CODE_DISABLE_WEB_FETCH is easy to underrate. Web fetch is where an agent pulls arbitrary page content into its context, which is both a prompt-injection path and a source of token bloat. In a locked-down environment you may simply want it off. A sketch of how I'd wire it in a settings file:

{
  "env": {
    "CLAUDE_CODE_DISABLE_WEB_FETCH": "1"
  }
}

The notes name the variable but I haven't verified which values it accepts, so check that "1" is what turns it off before you roll it out. Also test it: confirm the tool really refuses, rather than assuming the variable worked.

The auto-mode change is the opposite kind of knob. "Yes, but ask again next time" sits between approving once and approving forever, and it suits exactly the commands you're fairly sure about but don't want to whitelist. I'd expect it to cut approval fatigue without widening standing permissions, though that is a guess from the option's name, not something I've measured.

Two surfaces, one policy?

claude --desktop and the plugin configuration tooling are the ones that worry me, for the same reason. Each adds a surface. If a developer can start a session from the desktop app as well as the terminal, does your pinned model, your web fetch setting and your spend limit follow them? The gateway limit probably does, since it sits outside the client. The local settings are a question I'd test by hand, on a clean machine, with one of each.

Plugins raise the same question in another form. A configuration tool makes plugins easier to distribute across a team, which is great, and easier to drift, which is less great. Treat plugin config like any other dependency list: reviewed, versioned, owned by somebody.

/mcp reconnect all is the least political item on the list and probably the one people will use daily. It saves you restarting a session because one flaky server dropped. Fine. Just don't let it hide the fact that you have a flaky server.

My suggested order for a Monday morning: pin the model, set the gateway limit and find out its scope, switch off web fetch where you don't need it, then run the clean-machine test across terminal and desktop. Which of those four do you currently have in place?