[seongj-un]

Fixes #853

macOS — HookServer.swift

A failed accept() used to break out of the loop, so the server thread ended for good: the notch stopped updating and permission hooks fell back to the terminal until Coucou was relaunched. The loop now keeps going: transient errors (EINTR, ECONNABORTED) retry at once, anything else (e.g. EMFILE) after 100 ms, so a persistent error can't spin the CPU.

Windows — pipe.rs

When connect() failed, the loop retried on the same pipe instance, which fails the same way forever (ERROR_NO_DATA after a client connected and closed first). The failed instance is now replaced by a fresh one, created before the old one is dropped, so a listening instance always exists.

Testing

• macOS: xcodebuild -scheme NotchBuddy -configuration Debug build succeeds; scripts/test-claude-hooks.sh passes.
• Windows: not compiled locally (no Rust toolchain here); relying on the Windows CI.
• The failing accept() / connect() paths themselves weren't reproduced on a device, same as in the issue.

🤖 Generated with Claude Code

[afpruivo]

Tested the Windows side on Windows 11 Pro 26H2. It builds, cargo test --lib passes (473).

I tried to reproduce #853 by hammering the relay pipe (8 workers opening and closing connections for 10 s). The pipe did go dead, but not the way #853 describes: Coucou itself crashed with heap corruption (0xC0000374), on 0.5.2 and on this branch alike. I logged the loop on this branch, and the failed-connect() path never ran.

The crash is a known mio 1.2.3 bug in Windows named pipes (tokio-rs/mio#2011), fixed in mio 1.2.4. I opened #911 with that bump: same test, no crash.

So I couldn't trigger the ERROR_NO_DATA case here, but the change looks right to me: per the ConnectNamedPipe docs, an instance whose client already closed returns ERROR_NO_DATA until it's disconnected, so retrying on the same instance can't succeed, and creating the fresh one before dropping the old keeps a listener around.