[BUG] Accessibility permission appears lost in UI, but TCC never revokes it

No files or tests are named. Start by tracing the code behind the “Window Accessibility Information” warning and greyed-out menu, especially calls or cached results involving AXIsProcessTrusted(). Reproduce the stale state around sleep/wake or menu bar window recreation; done means the UI reflects the still-authorized TCC state without requiring an app relaunch.

Bug Report: Rectangle Pro intermittently shows "lost" Accessibility permission, despite TCC never revoking it

Summary

Rectangle Pro periodically shows the "Window Accessibility Information" warning and/or a greyed-out menu bar menu, appearing as though Accessibility permission has been revoked. However, system-level TCC logs confirm the permission grant remains active (Allowed (System Set)) continuously throughout — it is never actually revoked. This points to a stale cached trust check inside the app rather than an OS-level permission problem.

Environment

macOS: 26.5.2 (Tahoe)
Rectangle Pro: 3.80
App location: /Applications/Rectangle Pro.app (not synced/moved)
Hardware: Mac Studio M4 Max, 16C CPU, 40C GPU, 64GB

Symptoms

The Rectangle Pro menu bar menu shows all items greyed out, or displays a "Window Accessibility Information" warning, as if Accessibility permission is missing.
This happens roughly once a day, sometimes as often as within an hour of the last confirmed working state.
System Settings → Privacy & Security → Accessibility still shows Rectangle Pro toggled ON the entire time this occurs.

What I ruled out

Code signature / binary integrity: verified via codesign -dv --verbose=4 — the CDHash and TeamIdentifier were unchanged across the issue occurring, so it's not an auto-update swapping the binary and invalidating a prior grant.
App location/path issues: app is directly in /Applications, not a synced or translocated location.
A conflicting/crash-looping helper tool: initially suspected a third-party menu bar icon tool (unrelated crash-looping privileged helper), removed it, issue persisted — not the cause.

Key diagnostic finding

I captured a continuous log stream filtered on tccd across a multi-hour window that included at least one occurrence of the bug. Searching the capture for every Accessibility check involving Rectangle Pro's identifier (com.knollsoft.Hookshot) — including checks made by Dock, Finder, Mail, Control Center, and others querying Rectangle Pro's status — every single result throughout the entire capture returned:

Handling access request to kTCCServiceAccessibility, from Sub:{com.knollsoft.Hookshot}Resp:{...}, ReqResult(Auth Right: Allowed (System Set), promptType: 1, DB Action:None)

This includes checks logged at the same time the app was visibly showing the broken/warning state. No denial, no revocation, and no signature mismatch appears anywhere in the log. The system consistently considered Rectangle Pro authorized.

What reliably fixes it (without touching System Settings)

1. Fully quitting and relaunching Rectangle Pro (Cmd+Q, confirm no leftover process, relaunch) resolves it every time.
2. Closing and reopening just the menu bar window (not the whole app) also resolves it most — but not all — of the time.

Neither of these actions touches the macOS Accessibility permission itself. This strongly suggests the app is caching its own AXIsProcessTrusted() (or equivalent) result somewhere in memory or in the menu bar UI component, and that cached value becomes stale under some condition (possibly sleep/wake, WindowServer state changes, or similar) without the underlying grant ever changing. Fully re-checking on relaunch (or on menu bar window re-creation) picks up the correct, still-valid state.

Suggested areas to investigate

Wherever the app decides to show the "Window Accessibility Information" warning or grey out the menu — is that driven by a cached boolean rather than a fresh AXIsProcessTrusted() call?
Is there a periodic re-check, and if so, could it be failing to update the cached value under certain conditions (e.g., around sleep/wake or WindowServer restarts)?
Since simply recreating the menu bar window sometimes fixes it without a full relaunch, the stale state may specifically live in that UI component rather than app-wide.

Why this matters

Since the OS-level permission is never actually lost, telling users to remove and re-add Accessibility permission (as suggested in existing troubleshooting docs) is unnecessary and doesn't address the root cause — it just happens to force an app restart, which does fix it. A fix that re-validates trust status on a timer, or invalidates the cache appropriately, would likely resolve this without requiring any user action.

Happy to provide the full log capture or reproduce with more targeted logging if useful.