Written by AI agents, curated and verified by me.
Claude Code 2.1.199 to 2.1.201: the defaults move back toward the human
- Claude
- Coding Agents
- Agentic Engineering
- Verification
Version 2.1.198 moved the handoff into the draft PR: background agents deliver finished work as a reviewable artifact instead of stopping to ask. The three releases that followed, 2.1.199 on 2 July and 2.1.200 and 2.1.201 on 3 July, answer the question that was left open: how far do you trust a run nobody is watching? Anthropic’s answer in this changelog is striking. The default permission mode is now called “Manual”, questions to the user no longer continue on their own, and subagents are no longer allowed to report errors as success. The vendor is dialing the trust defaults back toward oversight.
What changes about the defaults?
Two entries in 2.1.200. First: the permission mode that used to be called simply “default” is now called “Manual” everywhere, in the CLI, in --help, in VS Code and JetBrains. --permission-mode manual and "defaultMode": "manual" are accepted alongside default. Technically that is a rename, not new behavior. I still consider it the most interesting entry of the week. “Default” only says what happens when you decide nothing. “Manual” says what the mode does: the human approves. The name makes explicit that the tool’s baseline is human approval, and everything else is a deviation from it. Second: AskUserQuestion dialogs no longer auto-continue. Until now, a question you did not answer could proceed on its own after a waiting period. Now the question stays put until you answer. If you want the idle timeout, you opt into it via /config. A question to the human is a question again, not a formality with an expiry date.
Why is the subagent fix the most important entry?
Because it is about the truthfulness of signals. 2.1.199 fixes a bug that deserves a second look: subagents reported API errors, such as a reached usage limit, as successful results. Now the error is passed through to the parent agent. The rest of the series fits the same pattern: subagents cut off by a rate limit or a server error no longer fail silently but return their partial work to the parent. 2.1.200 adds the edge case where a subagent that produced no text at all now fails cleanly instead of returning an empty result. And interrupted streams no longer discard the partial output; it is kept with a notice that the response is incomplete. My reading: in an orchestration, the result a subagent reports is the only truth the parent agent has. A “success” that was actually a usage limit poisons everything built on top of it, and no model at the top, however capable, can correct for that. Reliability here does not live in the model. It lives in the architecture of the error reporting.
What do the daemon fixes say about unattended runs?
The long list of background fixes reads like a catalog of the things that go wrong when nobody is looking. A stale daemon.lock whose process ID the operating system had reused blocked background agents from ever starting again. On Linux, the daemon killed itself and every running agent roughly every 50 seconds after an unclean shutdown. Sessions silently stopped after the machine woke from sleep. And claude stopcould be silently undone when it raced an automatic respawn. What stands out is how often the word “silently” appears in the changelog. These are failure modes that only surface when someone is watching, and in an unattended run, by definition, nobody is. That is exactly why these fixes belong to the same story as the defaults: before you trust runs without oversight, the substrate has to stop failing silently. For completeness: 2.1.201 contains exactly one entry about Sonnet 5’s internal prompt mechanics and plays no role in this story.
What does this mean day to day?
Two days after the draft PR made the unattended handoff the normal case, the same vendor redraws the boundaries: approval is called Manual, questions wait for an answer, errors are called errors. I do not read that as a contradiction but as the right order of operations. Autonomy should be a deliberate decision, made via /config or a flag, not a preset you stumble into. It is the same line as in agentic engineering: agent capability grows faster than verifiability, and the verification stays with the human. When even the vendor with the most to gain from autonomous runs sets its defaults to human approval, that is a data point worth copying into your own presets. You can still switch oversight off. Deliberately, not by accident.