Everything that changed in Claude Code over the summer of 2026

Claude Code shipped 81 releases between 1 June and 28 August 2026. That is nearly three per working day, and the official changelog carries no dates, so it is easy to lose track of what landed when. This article cross-references that changelog against the real npm publish dates and keeps only what changes how you work, rather than the full list. The Spanish version is at /claude-code-verano-2026/.

Key takeaways

• Between 1 June and 28 August 2026, 81 releases shipped, from 2.1.160 to 2.1.251, carrying 149 lines of additions and 120 of changes or removals.
• Claude Opus 5 arrived on 24 July in version 2.1.219 and became the default Opus model, with a one-million-token context window at the same price as Opus 4.8.
• Since 7 August, Claude Code sessions can message each other, even across different machines, using SendMessage and ListAgents.
• The same day brought self-hosted environments: claude self-hosted-runner executes web, mobile and desktop sessions inside your own network.
• The sandbox learned to show a sentinel value instead of the real secret and substitute it on egress, so a token stops appearing in logs.
• Check the removals too: the /agents wizard and the ultraplan feature are gone, and the "default" permission mode is now called "Manual".

A summer of 81 releases

The cadence matters for understanding the rest. The window runs from 2.1.160, published on 1 June, to 2.1.251 on 28 August: 30 releases in June, 23 in July and 28 in August. Together, those 77 changelog entries hold 149 lines starting with Added and another 120 starting with Changed or Removed.

That second figure is the one usually ignored and the one that costs the most time. A summer with 120 behaviour changes means a configuration that worked in May can behave differently in September without anyone touching it.

Claude Opus 5, the most visible change

Version 2.1.219, from 24 July, sums it up in one line: Claude Opus 5 becomes the default Opus model, with a one-million-token context window and fast mode at 10 and 50 dollars per million tokens. Standard pricing stays at 5 dollars per million input and 25 per million output, exactly what Opus 4.8 cost.

In the announcement, Anthropic positions it this way: "It’s the new default model on Claude Max, and the strongest model on Claude Pro". The figures accompanying the launch are concrete: on Frontier-Bench v0.1 it more than doubles Opus 4.8’s result, on ARC-AGI 3 it triples the next-best model, and on CursorBench 3.2 it lands within 0.5% of Claude Fable 5’s peak at half the cost.

Two practical details come with the change. First, the same release removed Opus 4.7 from fast mode, so /fast now applies to Opus 5 and Opus 4.8. Second, and easier to miss, a few days earlier 2.1.207 had made Opus 4.8 the default on Bedrock, Vertex and Claude Platform on AWS, so your default model depends on which door you come through. For context on the previous models, the site has the analyses of Opus 4.7 on long-horizon tasks.

Sessions stopped being alone

This is the conceptual shift of the summer. Until August, every Claude Code session was an island. Since 2.1.224, from 7 August, a session can send a message to another one, even if it lives on a different machine of yours, using SendMessage, and discover which ones are available with ListAgents. On macOS and Linux for now.

Version 2.1.236 added something on top that solves the obvious problem of coordinating two sessions: notify_when_idle asks another session for a single notice when it next goes idle. It is opt-in, fires once, and involves no polling, so waiting costs no context.

The design took the risk seriously. Messages aimed at a session running with bypassed permissions are not delivered on their own: they are held for your approval, governed by the crossSessionInbound and dialogExpiry settings. In late August, 2.1.248 extended messaging to Bedrock, Vertex, Foundry and installations with telemetry turned off.

Your own infrastructure for cloud sessions

The second headline of 7 August is self-hosted environments. The claude self-hosted-runner command turns your machines or containers into the place where sessions started from the web, mobile and desktop execute. It is in public beta for Team and Enterprise plans and ships disabled: an Owner has to enable it from the admin settings.

The mental model is a continuous-integration runner, and there are three pieces: an environment, which is a named destination, the runners, which are processes inside your network, and the sessions. When someone picks your environment, Anthropic’s control plane places the session on a queue, a runner claims it, clones the repository and starts a child Claude Code process on your machine.

What matters is the direction of the traffic. Everything is outbound HTTPS to api.anthropic.com, and the documentation says it plainly: "Anthropic never connects into your network".

Now the small print, worth reading before planning anything:

• What stays inside: repository checkouts, build artifacts, secrets, and any file the session creates.
• What leaves anyway: the entire conversation, with its prompts, responses and tool results, travels to api.anthropic.com for inference, and Anthropic stores the transcript. Self-hosting moves execution, not the model.
• Incompatibilities: unavailable to organisations with Zero Data Retention, and inference cannot be routed through Bedrock, Vertex, Foundry or your own gateway.
• Repositories: sessions check out code from GitHub.
• Fleet arithmetic: a runner locks to the first owner that claims a session and serves only that owner until it finishes, so the minimum fleet size is the number of people you expect active at once.

If what you want is to drive your own machine from your phone without building any of this, the answer is still Remote Control, which is available on Pro and Max.

The sandbox learned to hide credentials

Of everything that arrived this summer, this is the mechanism I liked most, because it attacks a real problem almost nobody measures: the token does not leak over the network, it leaks into a command’s log output.

Version 2.1.187 introduced sandbox.credentials in June, which lets you deny access to credential files and environment variables. The trouble with denying is that it breaks the tool: without GH_TOKEN there is no working gh. The answer came with mask mode, extended to files on Linux and WSL in August.

It works like this: the command inside the sandbox sees a per-session sentinel value, never the secret. When its request leaves for one of the hosts you authorised, the sandbox proxy swaps the sentinel for the real value. The command authenticates correctly, and neither it nor its logs ever touch the credential.

{
  "sandbox": {
    "network": {
      "tlsTerminate": {},
      "allowedDomains": ["api.github.com", "registry.npmjs.org"]
    },
    "credentials": {
      "envVars": [
        { "name": "GH_TOKEN", "mode": "mask", "injectHosts": ["api.github.com"] },
        { "name": "NPM_TOKEN", "mode": "mask" }
      ]
    }
  }
}

Three conditions are worth being clear about. First, the proxy needs to see the request contents to substitute the sentinel, so network.tlsTerminate is mandatory; without it masking fails, but it fails safely, because the sentinel reaches the server intact and authentication breaks, with a warning at startup. Second, these settings are only read from user settings, managed settings, or what you pass with --settings: a .claude/settings.json inside a repository is ignored, which is exactly what you want. Third, there is no built-in deny list, so only what you enumerate is protected.

For structured values, 2.1.224 added extract, a regular expression that substitutes only the captured group, useful when the variable is a connection string and the tool needs the rest to function. Also arriving were decode: "jwt" with maskClaims to mask specific JWT claims, and AWS SigV4 request re-signing. Anyone coming from isolating agents with containers will find the approach familiar; the site has the comparison with E2B as a code sandbox for agents.

Brakes after the fan-out era

July brought limits, and their story says something about how this is being calibrated. On 16 July, 2.1.212 set a cap of 200 subagents per session and another of 200 web searches, both meant to cut runaway loops.

Three weeks later, on 7 August, 2.1.224 removed the per-session subagent cap: long-running sessions were refusing new agents for no good reason. The concurrency and depth limits stayed, which were the ones that actually mattered. If you read about that cap in July, it is gone.

What does remain is more interesting than a number:

• Subagents no longer spawn nested subagents by default, since 2.1.217. You have to raise CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH to allow it.
• The cap on concurrent subagents stays at 20, tunable with CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS.
• Dynamic workflows aim at fewer than 15 agents by default since 2.1.219, as guidance rather than a hard limit.
• The 200-web-search-per-session cap is still there.

The underlying reading is that depth was closed and width was left open with a warning. That makes sense: a subagent spawning subagents multiplies spend without anyone seeing it coming.

Cost and cache finally became visible

August was the accounting month. Version 2.1.243, from 24 August, makes it possible for the first time to separate prompt-cache duration between the main conversation and subagents, with promptCacheTtl and subagentPromptCacheTtl: an hour on the long conversation while subagents stay at five minutes, which is exactly the split you want when a session lasts all afternoon.

The same release added modelPricing, so an organisation with contracted rates sees its real prices in /cost, the status line and telemetry instead of list price, and a loops breakdown in /usage with run counts, total tokens and tokens per run. Four days later, 2.1.251 added a per-session cache line to /cost with hit ratio, misses and re-cached tokens.

For anyone tuning spend, the combination closes an old gap: until this summer you could suspect the cache was not working, but not confirm it from inside the session.

What disappeared or was renamed

This list saves more time than any other, because these are things you will look for and not find:

• The "default" permission mode is now called "Manual" across the command line, --help, VS Code and JetBrains, since 2.1.200.
• The /agents wizard no longer exists since 2.1.198. Ask Claude to create the subagent, or edit the files in .claude/agents/ directly.
• The ultraplan feature was retired in 2.1.222.
• /deep-research only starts when you invoke it; Claude no longer launches it on its own.
• /code-review now runs as a background subagent, so a review no longer fills your conversation.
• /commit-push-pr stopped auto-approving git commands with dangerous flags such as --force, --amend or --no-verify.

Small details you notice daily

Beyond the headlines there are a handful of things you feel in daily use. --safe-mode, since 2.1.169, starts with no CLAUDE.md file, plugin, skill, hook or MCP server, which is the obvious first step when something behaves oddly and you cannot tell what causes it. The same release brought /cd, which changes the working directory without invalidating the prompt cache mid-session.

Permission rules gained precision in 2.1.178 with the Tool(param:value) syntax, which allows things like Agent(model:opus) to stop subagents from using Opus. And since 2.1.208 there is a screen reader mode with plain-text rendering, enabled with claude --ax-screen-reader or the axScreenReader setting.

## Start with no customisation at all, to diagnose a problem
claude --safe-mode

## Change directory inside the session without losing the prompt cache
/cd ../another-repository

## Stop subagents from using Opus, in .claude/settings.json
## "deny": ["Agent(model:opus)"]

GitLab also caught up with GitHub during August: plugin marketplaces from GitLab repositories, merge request URLs in --worktree and in the agents view, an MR badge in the footer, and automatic redaction of nine families of GitLab tokens in logs. If you work with a self-hosted GitLab or Gitea, as plenty of self-hosted setups do, that parity is welcome.

Frequently asked questions

Is a self-hosted environment worth setting up?

Only if your network, tooling or compliance rules demand it. The documentation itself recommends Anthropic-hosted environments for most teams, because self-hosting means building and maintaining the runner image, operating the fleet and controlling its network. And it is worth understanding what it solves: checkouts and artifacts stay on your infrastructure, but the conversation leaves for the API for inference anyway. If your goal is that no data leaves, this is not the answer.

Does credential masking protect outside the sandbox too?

No. sandbox.credentials affects only commands executed inside the Bash sandbox. To strip Anthropic and cloud-provider credentials from all subprocesses, sandboxed or not, there is the CLAUDE_CODE_SUBPROCESS_ENV_SCRUB variable. And on macOS file masking is unavailable: it falls back to denial, which breaks the tool but exposes nothing.

Which model is the default now?

It depends on the door you come through. On the Anthropic API, Claude Opus 5 has been the default Opus since 24 July. On Bedrock, Vertex and Claude Platform on AWS the default is Opus 4.8, since 2.1.207. If you want to pin it yourself, 2.1.236 added ANTHROPIC_DEFAULT_MODEL, which sets the model new sessions start on, while a manual /model pick still takes precedence and persists across restarts.

Conclusion

If the summer had to be summed up in one sentence, it is that Claude Code stopped behaving like a program you run and started behaving like a fleet you operate. Sessions talk to each other, they can live on your own infrastructure, they have concurrency and depth limits, and they finally show what they cost and how their cache is doing.

The reasonable next step is not to try everything. It is to open /config, look at which permission mode you are in now that "default" is called "Manual", and decide whether any of this summer’s three pieces solves a problem you already had: coordinating long sessions, moving execution into your network, or getting tokens out of your logs. For the rest, the changelog will keep growing three times a day. If you are comparing tools before deciding, the measured-task analysis of Claude Code against Cursor and Copilot is still a good starting point, as is the guide to deploying an AI agent to production.

Sources

1. Official Claude Code CHANGELOG
2. Publish dates for @anthropic-ai/claude-code on npm
3. Introducing Claude Opus 5 (Anthropic)
4. Self-hosted environments (Claude Code docs)
5. Configure the sandboxed Bash tool (Claude Code docs)