Claude Code: an MCP layer that retries, and an agent panel you can read

I already covered the orchestration-level fixes from the same update wave in Claude Code hardens orchestration: a depth limit for sub-agents, MCP calls that abort instead of hanging, /rewind after a /clear. The same versions carry a second layer of maintenance that gets less attention. It touches the wiring to the MCP servers and the panel you watch your agents through. In daily work both decide whether a run completes and whether you understand what it is doing.

What changed?

Three things that did not belong in the orchestration post. First, MCP connections now retry transient network errors instead of giving up on the first stumble. Second, the agent panel shows sibling agents again and stops jumping while you scroll. Third, CPU usage while streaming a response drops by about 37 percent. No new capabilities, just less friction at the points you only notice once they annoy you.

Why do retries make the MCP connection more resilient?

Because a transient network error is no reason to lose the whole call. Capability discovery, that is tools/list, prompts/list and resources/list, now retries transient network errors with short backoff. OAuth gets the same treatment: discovery and token requests retry once after a transient error, and headless environments skip the browser popup and go straight to the paste-the-URL prompt. There are clearer errors too. An HTTP 404 now shows the URL and points to your MCP config, and on startup Claude Code flags when an MCP server needs authentication, pointing you at /mcp. This is the unglamorous kind of hardening. A single dropped packet while opening a connection used to topple an agent run even though the second attempt would have worked. That is exactly the failure a retry absorbs.

What changes in the agent panel?

It becomes readable again. Two fixes: when you view a sub-agent, the panel no longer hides its siblings, and scrolling past the overflow cap no longer makes the list jump by a row. That sounds cosmetic, but it is the precondition for following a parallel orchestration at all. A panel that hides siblings lies about the state of the run. You see one agent and assume that is all of it, while three more work alongside. Reliability is also a question of visibility. You can only take responsibility for what you see, and the panel is where you see it.

What does the lower CPU usage buy you?

It makes long sessions and parallel agents more bearable. According to the changelog, CPU usage while streaming a response drops by about 37 percent, achieved by coalescing text updates to 100-millisecond intervals. If you fire a single prompt, you barely notice. If you run several agents at once or keep a session open for hours, you notice it in the fan and the battery. On top of that, the slow memory growth over long sessions from the terminal output cache was reduced. Both aim at the same point: the agent should stay calm even when it runs for a long time.

What does this mean day to day?

These three entries do not change what Claude Code can do, but how reliably it does it under sustained load. A retry saves a run that a brief network hiccup would otherwise have cost. An honest panel shows you what is really running in parallel. Lower CPU usage keeps the machine cool when a session refuses to end. It is the same line as in agentic engineering: reliability does not come from the model, but from the architecture around it, in the retries, the timeouts, and the view of the state. The responsibility stays with you. These updates only give you a fair chance to exercise it.

Sources

• Claude Code: Changelog