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

Abierto
  • ¿Algo no está bien?
#895 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
macos
Área
accessibility, desktop

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Sin datos de lenguaje
Estrellas
156
Forks
1
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rxhanson/RectanglePro-Community

Todos los issues de rxhanson/RectanglePro-Community

Issues similares

Más issues de Accessibility

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.