Follow Discord
Sweep 22 Oct 2026 · 04:32Z Build v2.1.308 527 read Stable v2.1.308 Latest v2.1.308 Next v2.1.308 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.224 ·

Invalid sandbox credential settings now fail closed instead of being ignored

A malformed sandbox.credentials block now denies everything instead of quietly disabling protection.

You'll notice Improvements
JSON All of v2.1.224
You'll noticeTier: how much it should matter to you
4Useful: my rating, 1 to 5
3Signal: worth watching, 1 to 5
SandboxArea: what it touches
ImprovementsKind: in v2.1.224,
What probably matters to youSection of the release
What

A malformed sandbox.credentials block used to be dropped entirely, leaving no credential protection in place. It now degrades to a deny-everything skeleton: all sigv4 signing modes deny, and implicit AWS credential pairing is suppressed rather than left open.

Details
  • Invalid awsPairs entries become non-functional suppressors built from the conventional AWS environment variable names, with a deterministic suffix so the result is stable across runs.
  • The sigv4 sub-keys streaming, presigned and sigv4a each degrade individually to "deny".
  • allowPlaintextInject degrades to an explicit false, so a lower-precedence settings file cannot turn it back on.
  • A single object where a list is expected is accepted as a one-element list with a warning.
  • A valid credentials block is salvaged out of an otherwise invalid sandbox value, with every other sandbox field ignored.
Evidence

The credentials block was salvaged from the invalid sandbox value and stays enforced; every other sandbox field was ignored.

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

Read from
Names in the bundlesandbox.credentials

See this entry in the whole of v2.1.224 →

Feedback