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.233 ·

Windows device-namespace paths are treated as network paths

On Windows, odd device-style paths are now blocked from attachments, uploads and deep-link directories.

You'll notice Bug Fixes
JSON All of v2.1.233
You'll noticeTier: how much it should matter to you
3Useful: my rating, 1 to 5
2Signal: worth watching, 1 to 5
WindowsArea: what it touches
Bug FixesKind: in v2.1.233,
Bug FixesSection of the release
What

Paths of the form \??\..., including ones that only take that shape after Windows normalization, now count as network paths everywhere the check is made. They are blocked for @-mention attachments and Chrome file uploads regardless of which network directories the session trusts, and deep-link working directories using them are rejected.

Details
  • One shared predicate now covers both \\ UNC paths and \??\ device-namespace paths; /net/<host> automounts are recognized by a separate predicate.
  • A per-module copy of the old check, which required a non-slash character after the two leading slashes and did no normalization, was deleted and its caller moved to the shared helper.
  • The executable-path check uses the combined predicate.
Evidence

Invalid cwd in deep link: UNC / network paths are not supported, got, network path not allowed:

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

See this entry in the whole of v2.1.233 →

Feedback