Claude Code update repairs recovery and tool execution controls

Anthropic released Claude Code 2.1.288 on October 2 with fixes for interrupted sessions, repeated external tool calls and enforcement of organization model choices. The official release was published at 20.19 UTC.

For teams running coding agents, those details affect whether work can continue after a failure and whether the same restrictions survive a restart. ByteForward has not independently tested this release.

Recovery after an interruption

Anthropic says noninteractive sessions and subagents now continue from partial responses after API timeouts. Resume fixes preserve context restored by compaction and address missing saved responses.

The session documentation explains why recovery is more involved than reopening a chat. As a conversation grows, Claude Code clears older tool outputs and summarizes earlier material. Detailed instructions can disappear during that process. Resuming continues an existing session, while forking creates a separate one with copied history.

A useful rollout check is to resume a representative task after compaction and verify the files, instructions and latest response that return. Seeing an old conversation title is a weaker test than confirming the working context the agent actually receives.

External actions need careful recovery

The release also addresses MCP calls that could execute twice when a remote result exceeded 16 MB or could not be parsed.

MCP connects Claude Code to external tools, databases and APIs. The official integration guide describes workflows that can create pull requests and email drafts as well as read information. A repeated call can therefore affect another system, depending on the tool and permissions involved.

Claude Code’s checkpoint documentation says local file recovery does not extend to remote databases, APIs or deployments. Restoring a conversation or file should not be treated as an undo operation for an external action.

When a response is missing, teams should inspect the destination before manually repeating consequential work. A client repair is useful, but it does not establish a universal guarantee that every connected service will process an action exactly once.

A failed check is not a blanket approval

Two control fixes matter for managed deployments. Restarted cloud sessions should no longer restore models rejected by an enforced organization list. Failed hook matching or tool input serialization now blocks the call instead of skipping PreToolUse and PermissionRequest hooks.

The model configuration reference distinguishes an initial selection from enforcement. Setting a preferred model does not itself prevent a user from choosing another. Administrators can restrict named selections and separately extend that restriction to the Default option. That distinction remains important when checking a restored session against the intended policy.

The hook fix has a specific scope. According to the hooks reference, other hook errors can still be nonblocking. A command hook that times out before a tool call does not automatically stop that call. The documented decision path depends on the event, return data and exit status. Teams should not assume every broken policy script now fails safely.

Test a deliberate denial, a broken handler and a timeout separately in a disposable environment. Confirm both the displayed result and whether the external operation occurred. These checks make the difference between having a policy configured and knowing how it behaves when something goes wrong.

ByteForward’s earlier provider controls coverage explains the deployment settings, while our mods report examines the access custom extensions can hold.

Hero image is original AI generated conceptual artwork created for ByteForward. It does not depict a product interface or tested result.