A WorkOS refresh reply lost at the 5 s deadline signs every client out #946

The WorkOS refresh POST is sent once with a 5 s deadline and never replayed. When WorkOS processes the exchange but the reply misses the deadline, the rotated tokens are lost. The next refresh comes a minute or more later, presents the retired token outside WorkOS's 30-second replay window, and gets invalid_grant. From then on every process sharing the token store (hooks, daemon, MCP servers, desktop app) is signed out until kcap login.

Observed on 2026-09-12: the daemon's proactive refresh timed out at 21:54:45 (5.2 s after send), the refresh at 21:55:41 got HTTP 400, and the daemon logged "Proactive token refresh was rejected" hourly until the next login.

WorkOS documents that a replay of the just-exchanged token inside the 30 s grace window returns the same rotated pair, and that timeouts, 5xx and 429 should be retried with the same token ("Never destroy a session on a transient failure"). The client should replay inside that window instead of giving up after one attempt.

Amplifier: the access token lifetime is 300 s, so the refresh runs every 3 to 5 minutes and each run is a chance to hit this.