Follow Discord
Sweep 25 Sep 2026 · 19:33Z Build v2.1.283 504 read Stable v2.1.274 Latest v2.1.283 Next v2.1.283 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.281 ·

Dir-sync first send waits behind another writer's lock and records more detail

Directory sync's first send now waits for another writer's lock to clear instead of failing, and reports more detail

You'll notice Improvements
JSON All of v2.1.281
You'll noticeTier: how much it should matter to you
1Useful: my rating, 1 to 5
1Signal: worth watching, 1 to 5
Cloud SyncArea: what it touches
ImprovementsKind: in v2.1.281,
ImprovementsSection of the release
What

When directory sync (the feature that copies your files through git) sends for the first time, it may find that another process on the same machine holds a lock, meaning that process is writing. Before, this counted as a failure. Now sync waits for the lock to clear. If the writer is on a different machine, sync stops waiting. Other changes:

  • The step that captures the current state can now report kept_here with reasons such as local_failures, or failed with uploads_failing.
  • The usage event tengu_dir_sync_git_capture_point gains a reason field, and the first-send data records writer_elsewhere and lock_waited.
  • A new install_ack trigger sends an update after incoming changes are applied.
  • The stopped state now reports whether the first upload happened.
  • Some waiting messages were reworded, for example "your message goes as soon as that clears."
Why

A second process writing to the same folder should no longer make the first sync fail. Instead, your message is sent as soon as the other process finishes.

How sure we are
One source agreesOne thing we can check says the same as this entry.
Anthropic's release notes agreeImproved screen-reader output in /mcp: a disabled server is read as "off" instead of "pending"

See this entry in the whole of v2.1.281 →

Feedback