Skip to content

v0.5.5 — Windows push delivery fix

Choose a tag to compare

View all tags
@michalekz michalekz released this 11 Jun 06:51
· 109 commits to main since this release
v0.5.5
dda9947

Patch release fixing real-time push delivery on Windows-native Claude Code.

Fixed

Windows push channel silently fell back to piggyback

Chokidar's default backend on Windows (`ReadDirectoryChangesW`) sporadically misses `ADD` events for files arriving via atomic `temp → rename`, especially with antivirus in the loop. Empirically confirmed:

  1. Sender writes message to receiver's `~/.claude-bridge/inbox//pending/.json`
  2. Receiver's chokidar watcher never fires on Windows
  3. Message gets delivered only via piggyback (next tool call), not inline as `` tag
  4. User starts Claude with `--channels`, sees `channels: enabled`, but feels like push doesn't work

Fix: force `usePolling: true` (200 ms interval) on Windows only. Linux/macOS keep native inotify/FSEvents — no regression. Polling adds at most ~200 ms latency vs. ~0 ms native, still orders of magnitude faster than waiting for the recipient's next tool call (which could be minutes if the agent is idle).

Why polling and not a smarter Windows backend

`ReadDirectoryChangesW` is the official native backend and has known atomic-rename event delivery gaps that aren't fixable from userland. Chokidar's docs explicitly recommend `usePolling` for reliability on Windows, especially with atomic writes (which we use throughout for inbox messages).

Verification

  • 213/213 unit tests pass on all platforms.
  • Behavior unchanged on Linux/macOS (native events).
  • Windows behavior fixed (polling).

See CHANGELOG.md for the full record.

Assets 2
Loading