It used to load the real SPA, and gave a solid, free linux calendaer app with notifications.
Yesterday it began landing on Notion’s “Notion Calendar can do more on your desktop / Download for Mac” page instead.
That URL isn’t a typo or DNS glitch: calendar.notion.so still returns 200.
The steer happens after their JS runs — a client-side navigation to www.notion.com product-calendar paths when their bundle / feature gates decide you’re not their supported desktop surface.
On Linux + Electron the signals are obvious if you don’t mask them:
Fixes made:
Main process: Set every request’s User-Agent to a fixed Chrome-on-macOS string. Strip Chromium’s Sec-CH-UA-* headers and replace them with macOS Client Hints. Turn off AutomationControlled via disable-blink-features. On https://calendar.notion.so/ main document requests, add Cache-Control: no-cache / Pragma: no-cache.
Preload (runs before their JS): In the main world, override Navigator.prototype so userAgent, platform, userAgentData (including getHighEntropyValues), appVersion, vendor, webdriver, and maxTouchPoints look like that same Mac Chrome profile. delete process.versions.electron when it exists.
HTML responses: For calendar.notion.so, www.notion.so, notion.so, app.notion.com, remove Content-Security-Policy (and report-only) on HTML so their bundle and our bootstrap aren’t blocked.
Navigation: If the window tries to go to https://www.notion.com under /product/calendar or /product/notion-calendar, cancel it and loadURL("https://calendar.notion.so") again. Only allow five of those in a row before stopping; View → Open Notion Calendar (home) clears the count.
Working again for now. Untill they decide to break it again. As always every change breaks someones workflow.
Obviously as a linux user it feels somehow targetted but I'm sure they had some non-enshittification reasons.
(Ok I'm not sure but I'm saying it so I sound like a good sport)