Claude Code v2.1.181 adds a /config command that changes agent behavior mid-session. The shift it signals is bigger than the syntax: control surfaces are moving from the vendor's config file to the user's prompt.
Most release notes tell you what got better. The interesting ones tell you what was wrong before, if you read them sideways.
Claude Code's v2.1.181 release adds a feature that looks minor on the page: a /config key=value command that lets you set any setting from inside the prompt, with /config thinking=false as the worked example. It works in interactive mode, in the -p flag, and in Remote Control, per the release notes. The same release adds a sandbox.allowAppleEvents opt-in.
The vendor framing is convenience. You no longer have to restart a session or edit a config file to change how the agent behaves. Fine. But sit with the implication. The reason this feature is useful is that, until now, the agent's reasoning depth and its sandbox boundaries were decisions made for you, somewhere upstream, and they stayed fixed for the length of a conversation. The defaults were the product. You got the behavior Anthropic chose, and changing it meant leaving the room.
What v2.1.181 quietly concedes is that those defaults were never going to be right for everyone, all the time, in the same session. That admission is the story. And it is not happening only at Anthropic.
The feature is a control surface, not a convenience
Strip the syntax away and look at what /config actually moves. It relocates two decisions, how hard the agent thinks and what it is allowed to touch, from a place you rarely visit (a config file, a startup flag) to a place you live in (the prompt).
The worked example Anthropic chose is telling. /config thinking=false turns reasoning off. Not on. Off. The default, in other words, is that the agent reasons, possibly more than you want, possibly slower and more expensively than the task requires, and the new lever exists so you can dial it down. That is a vendor acknowledging that its own default sits too far up the autonomy spectrum for some of the work people actually do.
The second addition, a sandbox.allowAppleEvents opt-in, points the same direction. AppleEvents are how macOS apps talk to each other and get scripted. The agent could not reach them. Now it can, but only if you say so, explicitly, opt-in. The capability expands and the gate stays shut until you open it.
Put the two together and a pattern appears that the release notes never names. Both changes hand the user a dial that used to be welded in place. One dial reduces autonomy on demand. The other expands capability on consent. The vendor is not picking a point on the spectrum for you anymore. It is handing you the slider.
This is the Capability vs. Controllability Frontier, made into a UI
There is a framework worth applying here. More capable agents are harder to control, and at some point a vendor has to choose a point on that frontier and ship it. Too much autonomy and the agent does things you did not sanction. Too little and it is a glorified autocomplete that pesters you for permission on every step.
For most of the last two years, that choice was made centrally. The vendor picked a default that was safe enough for the median user and capable enough to demo well, and everyone lived inside it. The choice was invisible because it was fixed.
What /config does is take a single point on that frontier and turn it into a range the user can traverse without leaving the conversation. Need the agent to move fast and stop deliberating? thinking=false. Need it to script your desktop apps? Open the AppleEvents gate. The frontier is still there. The trade-off has not gone away. It has just been handed to you, live, mid-task.
That is a genuinely different posture, and it is worth being precise about the cost. Centralized defaults are legible. There is one behavior, the vendor owns it, and when something goes wrong the blame is clear. User-controlled behavior trades that legibility for flexibility. The moment you can change the agent's reasoning and its reach from the prompt, the agent's behavior becomes a function of your last few commands, not the vendor's published policy. You gain control. You also inherit responsibility for the configuration you are now running.
The same week, three other vendors moved their own controls outward
The reason to treat this as more than a single changelog entry is that it does not sit alone in the window. Look at what landed around it.
OpenAI's agents framework shipped a release that, among other things, exposes sandbox error retryability metadata and exposes full, serializable MCP tool results. Both are about surfacing internal state outward: telling the layer above whether a failed sandbox call is worth retrying, and making tool outputs inspectable rather than opaque. That is the same instinct as /config. Stop hiding the machinery; expose it so someone upstream can make a decision.
E2B, which runs sandboxes for agents, shipped a fix that recognizes connection-dropped errors across Bun and Deno runtimes so that a sandbox killed mid-request reports as a clean TimeoutError instead of three different cryptic strings. Again: take an internal failure that used to leak as noise and turn it into a signal the caller can actually act on.
None of these is the same feature. I want to be careful here, because the temptation is to overclaim a trend from four release notes. But the shape rhymes. Across Anthropic, OpenAI, and E2B in roughly the same 24-hour stretch, the move is toward exposing and externalizing controls and state that used to be buried inside the runtime. The pattern resembles an industry collectively deciding that opaque defaults were a liability, not a feature.
What the vendor isn't naming: defaults are a governance decision
Here is the thing the release notes will never say out loud. When an agent's reasoning depth and sandbox reach are fixed by the vendor, the vendor is making a governance decision on your behalf, every session, silently.
That was tolerable when agents were toys. It stops being tolerable the moment the agent can script your desktop, touch your files, and act without asking. At that point the question of who decided this agent can do that becomes a real question with a real answer, and for a long time the answer was an invisible config the user never saw.
Moving allowAppleEvents to an explicit opt-in is the honest version of that decision. It does not assume. It asks. The capability exists, the gate is closed, and crossing it is a recorded act by the user rather than a default the user never consented to. That is the Trust Boundary Model applied correctly: the place where the agent crosses from reading to acting on your machine is exactly the place to put an explicit, user-owned gate.
The uncomfortable corollary is for everyone running agents they did not configure. The Shadow Agent problem, agents an individual installed without anyone in the org signing off, gets worse, not better, when behavior becomes promptable. A teammate can now widen an agent's reach with one line in a chat box. The control surface that empowers the careful user also empowers the careless one. Transparency cuts both ways: it tells you what the agent can do, and it tells anyone with the prompt how to expand it.
Aggregation logic explains why the controls moved now
Why would a vendor give up the simplicity of one fixed behavior? Aggregation theory offers an answer. The platform that owns the user relationship wins, and you do not own a relationship by dictating behavior to people whose work does not fit your defaults.
Claude Code competes for the same user as a half-dozen harnesses. The model underneath matters less than the experience of working with it day to day, which is the Harness Hypothesis in one sentence: the value is in the harness that connects the model to the world, not the model itself. A harness that forces you to restart a session to change how the agent thinks is a worse harness than one where you type a line. The friction was a defection risk.
So the move outward is partly competitive hygiene. Give the user the dials, keep the user. But it is also a tell about where these products sit on their own evolution. Early in a category, vendors ship strong opinions because users do not yet know what they want. As the category matures and users develop preferences the vendor cannot anticipate, opinionated defaults become a cage. The shift from fixed behavior to promptable behavior is what a maturing product looks like.
That maturity is uneven across the field. Some of the same-window releases are still housekeeping: Google's agent framework shipped a runner bug fix removing live event buffering, the kind of internal plumbing that keeps a project alive without telling you much about its posture. Not every vendor is at the control-surface stage. But the ones competing hardest for the daily user are clearly heading there.
The practical read for people who run these agents
If you use Claude Code, the actionable change is small and the mental-model change is large.
The small part: you now have two levers worth knowing. /config thinking=false when you want speed over deliberation on a mechanical task, and /config thinking back on when the work is genuinely hard. And the AppleEvents gate, which you should leave shut unless you have a concrete reason to let the agent script your Mac's other apps, at which point you open it deliberately and remember that you did.
The large part: stop thinking of your agent as having a behavior and start thinking of it as having a configuration you are responsible for. The defaults are no longer the whole story. What the agent does next depends on what you set, and that setting persists in ways that are easy to forget. An agent you told to stop reasoning will keep not reasoning until you tell it otherwise. An app-scripting gate you opened stays open.
The broader read, for anyone choosing between agent platforms: treat the presence of live, user-facing control surfaces as a maturity signal. A harness that lets you renegotiate autonomy mid-conversation is telling you it expects to be used for serious, varied work by people with opinions. A harness that hides those decisions is either earlier in its life or betting that its defaults are good enough for you. Sometimes that bet is right. Increasingly, the vendors competing hardest are deciding it isn't, and handing you the slider instead.
/Figures
| Dimension | Fixed defaults (before) | Promptable controls (after) |
|---|---|---|
| Who sets reasoning depth | Vendor, at startup | User, mid-conversation via /config |
| How to change it | Restart session / edit config | One line in the prompt |
| Sandbox app-scripting reach | Not available | Opt-in via sandbox.allowAppleEvents |
| Behavior legibility | High: one vendor-owned default | Lower: depends on user's last commands |
| Who owns the consequences | Vendor's published policy | User's running configuration |
/Sources
/Key Takeaways
- Claude Code v2.1.181 adds /config key=value, letting users change agent reasoning depth and other settings mid-conversation from the prompt, plus an opt-in sandbox.allowAppleEvents gate.
- The default example is /config thinking=false, a vendor conceding its own reasoning default sits too high up the autonomy spectrum for some work.
- The same window saw OpenAI's agents framework and E2B both externalize internal state and errors, suggesting an industry move away from opaque defaults toward user-facing controls.
- Promptable behavior trades the legibility of fixed defaults for flexibility, and the responsibility for the resulting configuration shifts to the user.
- Treat live control surfaces as a maturity signal when choosing an agent platform, but remember they make the Shadow Agent problem worse: anyone with the prompt can widen an agent's reach.

