agents · review · first seen Oct 27, 09:33 UTC
Anthropic fixes Claude Code stalls and session errors
Claude Code v2.1.311 shipped runner controls and fixes for freezes, context-limit errors, and late-connecting MCP tools. Builders whose work hits those cases have specific behavior to check before changing their workflows.
In short
- v2.1.311 shipped two self-hosted-runner idle-session controls.
- The named freeze and context-error fixes have specific triggering conditions.
- Late-connecting MCP tools are now available to subagents under the described condition; verify it in your workflow.
What shipped
Claude Code v2.1.311 shipped two self-hosted-runner options: --hold-idle-file and --max-hold-min. The release notes describe their purpose as keeping an idle session while the host reports processes it left running. That is a narrower change than a general promise that runner sessions will stay alive: it identifies controls for this situation, but does not establish how long any particular session will remain idle or what a host must report. [1]
The release also shipped a fix for long freezes at startup and after reading or editing files when a CLAUDE.md file contains a very long list item. The condition matters because the symptom can appear at several points in a normal editing session, not only when Claude Code first opens. The notes identify the file shape and the affected moments; they do not give a list length at which a freeze begins. [1]
Two other shipped fixes address sessions that could stop being useful without the underlying task being complete. When a standard-context request runs over 200K tokens, Claude Code now compacts the conversation and continues instead of stopping with a “Usage credits required for 1M context” error. Subagents can now use MCP tools from servers that finish connecting after the subagent starts. These are distinct failure cases: one concerns continuation after a context threshold, while the other concerns when a tool connection becomes available. [1][2]
Why it matters if you build
If a builder maintains a CLAUDE.md with long list items, the freeze fix gives a direct test case: repeat a startup, read, or edit that previously stalled. A successful repeat would be useful evidence for that workflow. It would not prove that every Claude Code stall is fixed, because the described fix is tied to a very long list item in that file. [1]
For standard-context work that crosses 200K tokens in a request, the reported behavior changes from an error to compaction and continuation. That may let a session proceed where it previously stopped, but compaction is still an intervention in the conversation. The release excerpt does not quantify what information remains available afterward, how much the continuation costs, or whether every request over that threshold completes. Treat continuation as the behavior to verify, not as a guarantee about output or credits. [1]
For a workflow that starts subagents before every MCP server has connected, the fix removes a stated timing failure: those subagents were unable to use tools from servers that connected later. The runner options address a separate operational case in which a host reports processes left running while the session is idle. Neither claim establishes that late connections always succeed or that idle sessions can be held for any chosen duration; test each condition in the workflow where it matters. [1][2]
How to try it today
- Use Claude Code v2.1.311 for a task involving a CLAUDE.md file with a very long list item. Check startup and a read or edit for the previously described freeze.
- In a standard-context session, check what happens when a request runs over 200K tokens. Look for compaction and continuation rather than the stated 1M-context credit error.
- Start a subagent before an MCP server finishes connecting. After the server connects, check whether the subagent can use its tools.
- If you use self-hosted-runner and your host reports processes it left running, examine --hold-idle-file and --max-hold-min, then check the idle-session behavior against your need.
What we checked
Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.
-
shipped L0 · primary
Claude Code v2.1.311 adds --hold-idle-file and --max-hold-min to self-hosted-runner.
per GitHub releases · anthropics/claude-code (L0) -
shipped L0 · primary
Claude Code v2.1.311 fixes long freezes caused by a very long list item in CLAUDE.md.
per GitHub releases · anthropics/claude-code (L0) -
shipped L0 · primary
Claude Code v2.1.311 compacts and continues standard-context sessions that run over 200K tokens instead of stopping with a 1M-context credit error.
per GitHub releases · anthropics/claude-code (L0) -
shipped L0 · primary
Claude Code v2.1.311 fixes subagents being unable to use MCP tools from servers that connect after the subagent starts.
per GitHub releases · anthropics/claude-code (L0)
What is not confirmed
The release excerpt does not establish a minimum list-item length for the CLAUDE.md freeze, a performance improvement across other files, or a fix for unrelated stalls. It does not state what compaction retains, the cost of a request that crosses 200K tokens, or a general change to 1M-context access. Those should not be inferred from the reported fixes. [1][2]
The excerpt does not give a maximum effective idle hold for a particular host or say that every MCP connection will succeed. The runner controls and late-connection fix describe behavior to test, not measured reliability for an individual setup. [1][2]
Who should act, who should wait
Move now if a current Claude Code workflow matches one of the named failures: a very long CLAUDE.md list item, a standard-context request running over 200K tokens, or a subagent that needs tools from a server connecting after it starts. The shipped fixes give you specific before-and-after checks. Self-hosted-runner users with hosts reporting processes left running also have named controls to evaluate. [1][2][3][4]
Wait before treating this release as a general stall remedy, a predictable credit outcome, or an idle-session guarantee. If your workflow does not match the conditions in the notes, these claims do not establish a benefit for it. Test the matching behavior first, then decide whether to change your usual setup. [1][2][3][4]
Sources
- v2.1.311 — GitHub releases · anthropics/claude-code L0 · primary