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

Đang mở
  • Có gì không ổn?
#895 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
macos
Lĩnh vực
accessibility, desktop

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Không có dữ liệu ngôn ngữ
Star
156
Fork
1
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của rxhanson/RectanglePro-Community

Tất cả issue của rxhanson/RectanglePro-Community

Issue tương tự

Thêm issue về Accessibility

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.