Web Minutes on macOS: When Screen Recording Permissions Kill the App
I installed Web Minutes (app) from OrchardKit because I needed something simple: track how long I actually spend in the browser during work hours. Not theoretical productivity — real numbers. Sonoma 14.5, MacBook Air M2, clean user profile. Should’ve been boring.
Instead, it launched once, showed an empty dashboard, and then refused to record anything. No timers moving, no stats updating. Just a polite UI doing absolutely nothing.
That’s worse than a crash. At least crashes are honest.
What Was Actually Broken
The first clue was a tiny warning in the interface about “Screen Recording permission required.” I’d seen that before with screenshot tools and streaming apps. Since Catalina, Apple treats screen capture as sensitive access.
Apple documents the Screen Recording permission model here: https://support.apple.com/en-us/HT210321
So I went straight to:
System Settings → Privacy & Security → Screen Recording.
Web Minutes wasn’t even listed.
That’s when I made my first wrong move. I assumed reinstalling would reset the permission prompt. Deleted the app, re-downloaded, launched again. Same behavior. No permission dialog, no tracking.
Then I checked whether there was an App Store version, thinking maybe the sandboxed build would behave better: https://apps.apple.com/us/search?term=Web%20Minutes
Nothing clearly official there, so this was definitely a direct distribution build.
The Real Culprit
The tool needs screen capture access to read browser window titles and active time. If macOS blocks that, it just sits idle. But here’s the catch: macOS only triggers the Screen Recording dialog the first time the app actively requests capture APIs. If that request fails silently or gets interrupted, you end up in a weird half-authorized state.
I opened Console.app and filtered logs by the bundle ID. There it was:
CGPreflightScreenCaptureAccess returned kCGErrorPermissionDenied
So the system was denying access before the UI could even explain what was happening.
Apple’s developer documentation on screen capture APIs explains how this works under the hood: https://developer.apple.com/documentation/screencapturekit
That confirmed my suspicion: the permission request likely fired during first launch, maybe before the UI finished initializing. I probably dismissed something too quickly.
What Actually Fixed It
The real fix wasn’t reinstalling. It was resetting macOS’s privacy database.
I ran:
tccutil reset ScreenCapture
Then rebooted. That part matters. Without rebooting, macOS sometimes caches the old denial.
After restart, I launched Web Minutes again. This time, a proper system dialog appeared asking for Screen Recording access. I approved it. macOS required a restart of the app to apply changes (normal behavior).
Second launch — timers started moving instantly. Browser titles detected. Data flowing.
I found this page helpful while double-checking how macOS handles operational permissions for tracking tools: https://deadtriggermod.xyz/office-and-productivity/56202-web-minutes.html
It lined up exactly with the behavior I saw — the app isn’t broken, it just depends entirely on OS-level capture rights.
Subtle Detail Most People Miss
After granting permission, macOS doesn’t fully enable capture until you quit and relaunch the app. Just closing the window isn’t enough. You have to ⌘Q it. I confirmed in Activity Monitor that the process was fully terminated before reopening.
Also, if you use multiple user accounts or migrated from an older Mac via Time Machine, TCC entries can carry over inconsistently. That explains why some people report the feature working instantly and others get the silent failure.
Performance-wise, once authorized, the utility barely touches CPU — around 3–4% when actively monitoring. Memory footprint sits under 150MB. No noticeable battery drain on the M2 Air. So there’s no inherent performance bug here.
If I Were Setting It Up Again
I’d do it cleanly from the start:
- Install to /Applications.
- Launch once.
- Immediately grant Screen Recording when prompted.
- Fully quit and relaunch.
- Confirm in System Settings that it’s toggled on.
That’s it.
The irony is that nothing was technically “wrong.” macOS privacy controls are just extremely literal. If the first permission request fails or gets skipped, the app looks broken when it’s actually just locked out by design.
OrchardKit’s build behaved correctly once macOS let it. The friction was entirely between the utility and Apple’s security layer.
Lesson logged: when a tracking or productivity tool shows an empty dashboard on modern macOS, assume permissions first — not bugs.