Time for a Reboot? macOS Tahoe Has a ’49-Day Itch’
Toggle Dark Mode
If you’ve run into an odd problem where your Mac stops communicating with the internet, the solution might literally be as simple as the old cliché of turning it off and back on again.
That’s because researchers have discovered a new bug in the macOS networking stack that breaks virtually all network connections after exactly 49 days, 17 hours, 2 minutes, and 47 seconds. If you happen to leave your Mac going without a reboot for that long — even if you put it to sleep in between — it will lose all ability to communicate over nearly every common network protocol.
It’s an odd problem that I’ve already run into at least once. I originally poked around a bit, trying to disable and re-enable Wi-Fi and my Thunderbolt Ethernet adapter with no success before finally shrugging and simply rebooting my Mac, after which everything was back to normal. However, it turns out there’s a method to this madness, and it’s a design flaw that likely crept into macOS with last year’s Tahoe release.
While the timeframe of 49 days, 17 hours, 2 minutes, and 47 seconds sounds weirdly random and specific, that’s only true when it’s expressed in those units. Convert that time into milliseconds — a unit that macOS uses under the hood — and you come up with a number that’s the upper limit of an unsigned 32-bit integer. Basically, it’s the classic “Y2K bug” in a different form.
The specific issue was initially discovered by Photon, a company that operates an open-source framework to connect agents to iMessage. As such, it runs a bunch of Macs as iMessage gateways, and these undoubtedly have uptimes that would normally exceed the 49-day-and-then-some threshold that triggers this bug. However, rather than just shrugging it off and rebooting it, they decided to dig deeper, finding what they called a “Ticking Time Bomb in macOS.”
Every Mac has a hidden expiration date. After exactly 49 days, 17 hours, 2 minutes, and 47 seconds of continuous uptime, a 32-bit unsigned integer overflow in Apple’s XNU kernel freezes the internal TCP timestamp clock… ICMP (ping) keeps working. Everything else dies. The only fix most people know is a reboot.
Photon’s blog post is an awkward read, at best (John Gruber suspects it’s “AI-generated slop,” and I can’t disagree that it certainly reads like that), but the actual bug is far less complicated than the post makes it out to be, as Photon is diving deep into the weeds here. However, the core issue basically comes down to how some networking-related code in macOS handles time.
What’s Going On Here?
To put it in a nutshell, the number of milliseconds since your Mac was last restarted is stored in an unsigned 32-bit integer. That gives it a maximum value of 4,294,967,295 (that’s 2^32 – 1 for the binary math nerds). Convert that into a more human-readable representation of time, and you get 49 days, 17 hours, 2 minutes, and 47 seconds (or 47.295 seconds, for those of us who appreciate being pedantically precise).
Once it reaches that value, it resets back to zero, which completely throws off the Mac’s networking stack, causing the TCP connection stack to effectively lose its mind as it stops properly tearing down “expired” connections (since the clock now thinks they were created in the future and therefore haven’t expired yet). These connections effectively remain open indefinitely (or at least for another 49 days and 17 hours or so), choking the system as it runs out of room to create new ones.
While it’s not entirely clear when this bug surfaced, many folks — myself included — have had Macs that have remained running for far longer than 50 days without incident prior to macOS Tahoe. Gruber also points out that Apple’s open-source XNU kernel code shows a smoking gun modification made six months ago, despite nearly everything else in there having remained unchanged over the past five years. That strongly points to a change in macOS 26, although it remains unclear why any Apple engineer would have done this, we can only assume there was a reason — and that the resulting bug simply slipped through the cracks.
It’s unclear if the macOS 26.4.1 update that was released today will address this, but we’re not holding our breath for 49 days, 17 hours, 2 minutes and 47.295 seconds to find out. For now, the good news is that this problem not only has a simple fix — just reboot your Mac every 49 days — but it’s also unlikely to be encountered by too many people, since Apple doesn’t usually let macOS go that long without several updates, any of which will be accompanied by a reboot as part of the installation process.
