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

A third file-sync transfer path, "direct", is built on both sides but unreachable

File sync gained a third "direct" transfer path through a file store, but it never runs.

Nothing to try yet In Development
JSON All of v2.1.246
Nothing to try yetTier: how much it should matter to you
2Useful: my rating, 1 to 5
0Signal: worth watching, 1 to 5
File SyncArea: what it touches
In DevelopmentKind: in v2.1.246,
In DevelopmentSection of the release

Both halves of a direct file transfer path are built, but the client driving it defaults to null and nothing supplies one.

What

File syncing gained a third way to move file contents, called direct, which uploads and downloads through a file store endpoint instead of inline. Both the sending and receiving halves exist, with size and deadline options, but the client that would drive it defaults to null and nothing in this build supplies one, so the path never runs.

Details
  • Tuning options exist as directMinBytes, directInboundMaxBytes and directDeadlineMs.
  • Even with a client supplied, the path only activates if the server answers that it offers the lane.
  • The record of how each file was transferred changed from a fixed two-value choice to a free string of up to 32 characters; anything unrecognised becomes "unknown", and a record marked "unknown" is refused on write.
  • Three new server refusal codes accompany it: synced_file_direct_upload_unavailable, synced_file_direct_download_unavailable and synced_file_lane_denied.
Evidence

synced_file_direct_upload_unavailable

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.246 →

Feedback