Back to Blog
claude-codeweekly-updatesonnet-5-5 +5 topics

What's Up Claude Code: Week of September 28th

Sonnet 5.5 becomes the default API Sonnet, Claude Code mods open up deeper customization, and a run of permission-rule fixes makes verification and plugin trust especially timely.

Olivier Legris Calculating read time…
In this article

TL;DR

This week’s story is control: a new default model, a powerful new extension layer, and fixes to permission handling. Anthropic launched Claude Sonnet 5.5 on September 28 and made it the default Sonnet model on the Anthropic API. On October 1, Claude Code added mods, TypeScript plugins that can reach deeper into the agent loop and interface. The official Claude Code changelog also records fixes in versions 2.1.288 and 2.1.289 around permission rules and sandbox auto-allow.

The common thread: more capability is landing closer to the boundary between an agent and your machine. That makes model evaluation, careful plugin review, and independent checks of permission behavior more important—not less.

1. Sonnet 5.5 becomes the default API Sonnet

Anthropic introduced Claude Sonnet 5.5 on September 28. The Claude Code changelog lists it as the new default Sonnet model on the Anthropic API, with a one-million-token context window. Anthropic describes it as faster and lower-cost for most work; those speed and cost comparisons are the company’s claims, not a guarantee for every workload.

A new default changes real workflows even when no one edits configuration. Before relying on it for a production task, rerun a small evaluation set that reflects your repository: accepted changes, test outcomes, review time, latency, and actual spend. Check model availability and behavior separately if you use Bedrock, Vertex, Microsoft Foundry, or a gateway; defaults and rollout timing can differ by provider.

The useful question is not “is the new model better?” in the abstract. It is whether the model improves your cost per verified result, including retries and human review.

2. Mods make Claude Code far more extensible—and raise the trust bar

On October 1, Anthropic announced Claude Code mods, small TypeScript functions bundled in plugins. Mods can change prompts, intercept tool calls, affect permission decisions, redact tool output, and customize parts of the UI. Anthropic says some built-in features, including /diff, are now implemented as mods.

This is a meaningful expansion beyond extensions that simply add commands or tools: a mod can participate in what the agent does, not just what it can call. That makes the feature interesting for teams building review aids, workflow-specific controls, or custom interfaces—and a materially different trust decision from installing a conventional prompt or skill.

Anthropic explicitly warns that mods run with Claude Code’s access to the machine and are not sandboxed. Treat them as executable code: inspect the source, understand what it can read or change, and install only from authors and marketplaces you trust. The announcement describes a sec-default mod for managed Team and Enterprise environments; administrators should still confirm which policies are actually managed and test them in their own setup.

3. Permission fixes deserve a deliberate upgrade check

The official Claude Code changelog lists versions 2.1.288 (October 2) and 2.1.289 (October 3). Among the fixes in 2.1.289 are cases where Bash deny or ask rules could be skipped under sandbox auto-allow, including commands with a leading variable assignment or an environment-variable prefix. It also fixes a nested-command permission rule not holding over a user-installed mod’s approval on managed machines.

A changelog entry establishes that these behaviors were fixed; it does not establish whether a particular installation was exposed or affected. If your workflows depend on these controls, check your installed version, review the exact release notes, and test representative allowed and denied commands in a disposable environment. Don’t infer that “sandbox enabled” makes every extension or code path safe: Anthropic’s mods documentation says mod processes themselves are not sandboxed.

Community projects worth looking at

I couldn’t verify a Claude Code community project with both an in-window discovery date and primary-source details for September 28–October 4. Rather than promote an older project as new this week, I’m leaving this section empty. The official mods getting-started guide includes sample ideas such as a context-window display and a preview before risky commands, but those are Anthropic’s examples—not independently discovered community projects.

Community events

The Clauders events index is the source of truth for dates, locations, and registration links. Check the live listing for this week and the week ahead; event details can change, and a listing is not evidence that an event took place. I could not verify a dated event inside September 28–October 4 from the accessible records, so I’m not claiming one here.

What I’m watching

  • Does Sonnet 5.5 lower cost per verified task on representative repositories, once retries and review are counted?
  • What review, provenance, and administrative controls emerge as teams start installing mods?
  • Do permission and sandbox fixes behave as intended across shells, operating systems, and managed settings?
  • Can plugin ecosystems make trust and maintenance signals visible enough for users to make informed choices?

For a low-risk test this week: compare the new model on a pinned task set, and evaluate any mod in a disposable project before granting it access to valuable code or credentials. More power is useful when the boundary is clear—and verified.