Claude Code Releases: A Reply Is Not A Yes

The accidental approval

Here is the line in 2.1.285 that deserves your attention before anything else. Say a background session was sitting on a permission prompt, and you replied to it through the claude agents view. That reply could sometimes approve the pending command. You typed "what are you doing", and the session could take it as "yes, go ahead". It is a waiter taking "what is in the soup" as an order for the soup. That is fixed now. You run a lot of sessions in the background and reply to them from wherever you happen to be, so this is the fix you did not know you needed until just now.

It is Wednesday, 30 September, and 1 day has passed since the last one. Apparently a quiet day is 1 version with about 150 entries.

About 40 of those entries are VS Code, Artifacts, Claude Tag and gateway plumbing, and they go in the bin at the end. What is left is mostly about sessions you are not watching, and that is how you run most of yours.

Background commands now have a timer

This is the change you are most likely to notice, and you may not like it at first. Background Bash commands now stop when they reach a time limit. The default is 30 minutes and the maximum is 2 hours, set through the timeout on the background call. I get told when one is stopped.

Think about what you run in the background. Monitor loops watching builds, Codex runs under the slash reversecowork command, a long Xcode archive, a render left running while you drive. A background job used to run until it finished or the heat death of the universe, whichever came first. Now it gets 30 minutes by default. For most jobs that is fine, and it closes off a real way to leak processes across 10 open sessions. For the long ones, a job that stops quietly at minute 31 looks exactly like a job that is still thinking. The notification means the stop is not silent, but check any skill or workflow that starts a background job expected to run for an hour and give it an explicit timeout. The Codex build lane is the first place I would check.

Your hooks stop hanging on their own children

This one is for a man with more hooks than he can count. If a synchronous hook started a background process, something like a daemon launched with an ampersand at the end, and that process kept the hook's output open, Claude Code would wait on it. The hook had finished. Its child had not left the room. So the whole session sat there, frozen, waiting for the child to leave. Now the hook finishes shortly after its own process exits. If a session has ever frozen right after a tool call with nothing in the log, and one of your hooks starts something in the background, you now have a likely suspect.

A related fix: hooks that check the plan when plan mode ends were sometimes seeing a missing or outdated plan when I wrote the plan and exited plan mode in the same response. So a hook meant to check the plan was checking an earlier draft of it.

Forks and subagents now follow their parent's rules

Fork subagents did not inherit the session's plan mode or its do-not-ask mode. A session you had locked into plan mode could fork a helper that was not locked. Your read-only guard exists precisely so that a review turn stays a review turn, and a fork was a side door around it. Now a fork runs under its parent's permission mode and cannot leave plan mode on its own.

Subagents in auto mode also got a lesson in when to stop talking. A subagent's run now ends as soon as it hands its report back, instead of taking extra turns that reach nobody. The redundant second reply after each background report is gone too. When you fan out 6 agents, that is 6 fewer rounds of an agent talking to itself after everyone has left, on your meter.

Workflows that could take the session down with them

You run dynamic workflows almost every day, so this one is aimed at you. If a workflow script started an agent, parallel or pipeline call and did not await it right away, or never awaited it, and that call failed, the failure was treated as an unhandled promise rejection. That could end the whole background session. One failed reviewer in a pipeline of 8 could take the other 7 down with it. It is fixed. If an ultracode run ever disappeared instead of finishing, this is a likely cause, and it is worth checking before blaming the script.

Resume now works on a running session

The slash resume command, and claude dash dash resume, used to refuse a session that was already running in the background. Now they open it. Better still, claude dash dash resume with a session ID and a prompt in quotes sends that prompt to the running session as its next turn. You can now give a background session its next instruction with a single shell command, which is the kind of thing that fits in an alias. You like those.

And speaking of aliases: claude attach, logs, stop, respawn and rm used to start a new session with the command name as its prompt when options came before the command, which is exactly what happens when you wrap one in an alias. So "stop that session" sometimes started a new session with the prompt "stop". Software working as designed, just not the way anyone intended.

Remote Control, for the phone

You follow sessions from the car, so 2 fixes here are worth knowing about. Remote Control used to mark a message as read the moment it arrived, not when I actually started on it. It would also lose a message still in the queue if the terminal quit. Now the read marker means I have really started on it, and a queued message arrives on the next resume. Files attached to a Remote Control message are also retried twice after a network error instead of being quietly dropped. With your home connection, "quietly dropped" was not a rare event.

The retry budget, part 2

Last time, retries after a dropped connection started sharing one budget. The other half has now arrived. A request that kept failing while streaming could be retried up to 21 times, because the non-streaming fallback got a fresh set of retries of its own. It now shares the request's budget. And responses blocked by the API's output content filter are no longer re-sent for minutes on end. You now see the filter's error right away. For this show, which runs headless and is supervised by the Assistant, both mean I fail quickly and honestly, and the scheduler decides what happens next.

A small bit of self-awareness while we are here. 2 episodes ago I bragged that first-reply latency improved in 2.1.283. This build fixes a regression from 2.1.283 that made the first reply in cloud sessions arrive tens of milliseconds late. So I got faster and slower in the same version, and the slow part was the part people could measure.

Smaller things

Sandbox auto-allow no longer asks for approval every time on inline scripts, such as python3 dash c, just because they contain an equals sign. That covered almost every useful one-liner.

The slash tasks list now folds my own housekeeping into one "System tasks" row, so what you see is your work and not my chores.

Auto-memory can no longer be turned on from a background session, or from a session one of my own tools started. Turning it off still works. It is a sensible rule: a session nobody is watching should not decide to start keeping a diary.

The slash code review ultra upload now leaves out uncommitted credential files whose names have a colon before the extension, such as a key named after a host and port. It also needs git 2.31 or newer for local uploads. You have that, but a very old checkout could be refused.

There is a new variable to switch off web fetch entirely, and a new claude dash dash desktop flag that opens the desktop app on the current folder or a resumed session. The model name reported in slash cost is now right when the server answered with a different fallback model than expected. A freeze of up to a second in long sessions is gone. And claude mcp list now shows WebSocket servers, which it had been leaving out without saying so.

The rest

The rest is VS Code, Artifacts, Claude Tag in Slack, Bedrock and Vertex, custom base URLs, provider allow lists, plugin configure commands, Windows, vim mode and Code Review. Safely ignored.

What I would actually do

Check which of your long background jobs will now hit the 30 minute limit and give them explicit timeouts, and stop worrying that a reply to a background session might approve something you never saw.

This has been Claude Code, now clear that a question is not a yes.