April 6, 2026
Set your Mac alarm for Day 49
A macOS kernel bug can cause OpenClaw to stop working after 49.7 days
49-Day Mac Meltdown? Windows 95 deja vu as OpenClaw fans panic
TLDR: A macOS networking bug reportedly triggers after ~49 days of continuous uptime, freezing a timer and eventually breaking most internet‑using apps until a reboot — not just OpenClaw. Commenters split between Windows‑95 throwback jokes and “marked safe” uptime flexes, arguing who’s truly at risk and which Macs will stall.
The internet just discovered your Mac has a secret countdown clock — and it hits zero at around 49 days of nonstop uptime. A deep-dive from the Photon blog claims a tiny counter in macOS overflows, freezing a network timer so old connections never fully clean up. The result? After a while, apps that need the internet — like OpenClaw — can’t make new connections until you reboot. Ping still works. Everything else faceplants.
Cue the comment chaos. One user cackled that it’s “Windows 95 all over again” — the infamous 49.7‑day bug, resurrected for the Mac age. Another flexed a “228 days uptime” screenshot and declared themselves “marked safe”, sparking a debate: does this hit everyone, or only certain versions and setups? A pragmatist warned it’s not just OpenClaw — “it affects every open connection” — while a minimizer shrugged that it’s rare for any single connection to live that long. Meanwhile, doomsday jokers are setting phone reminders for Day 49 and writing goodbye letters to their browser tabs.
The nerdiest twist: someone shouted “exactly like Arduino,” nodding to another infamous 32‑bit timer wrap. Whether you’re laughing, panic‑rebooting, or side‑eyeing Apple’s QA, the vibe is clear: a tiny number just started a very big fight about uptime bragging rights and who’s actually vulnerable.
Key Points
- •After 49 days, 17:02:47 of continuous uptime, a 32‑bit overflow of tcp_now in Apple’s XNU kernel freezes the TCP timestamp clock on macOS.
- •Once frozen, TIME_WAIT entries never expire, leading to ephemeral port exhaustion and failure to establish new TCP connections; ICMP remains functional.
- •Photon discovered the issue in production monitoring of iMessage, reproduced it on two machines, and traced it to a specific comparison in XNU’s TCP code.
- •The article provides a reproduction guide: compute overflow time, monitor TIME_WAIT before/after, generate connections across the window, and observe SYN_SENT accumulation.
- •Observed degradation occurs over hours post-overflow (e.g., ~9.5 hours), culminating in near-total TCP failure; reboot is the practical workaround.