Contents
What the message actually means
To move a window, the app asks macOS for the *accessibility element* representing the frontmost window — an object exposing that window's position, size and title. It then writes new values to it. When the log prints that it is unable to obtain the accessibility element, the very first step failed. There is nothing to resize because macOS did not hand back a window object.
The menu items grey out because the app is being honest: it cannot determine where the current window is, so it will not offer to move it. That is a symptom, not the fault.
Click on the Finder, or on TextEdit, then open the menu again. If the items are now enabled, the fault belongs to the other application. If they remain greyed out no matter what is in front, the fault is your Accessibility permission. These two require completely different fixes, and this five-second test tells you which one you have.
Cause A: the permission is out of sync
If everything is greyed out regardless of the frontmost app, macOS is refusing accessibility access altogether. The toggle in System Settings will usually still appear to be on, which is why people rule this out incorrectly.
The fix is to delete the privacy record and let it be requested again. Order matters: disable the toggle first, then remove the row with the minus button, then restart, then relaunch and accept the prompt. The terminal equivalent:
This is the same reset described in the full diagnostic guide, and it is the correct response to greyed-out menus that persist across every application.
Cause B: the frontmost application is not a good citizen
Far more often the menu greys out only when a particular application is in front. That application is not exposing standard window information, and no window manager on macOS can do anything about it — the same limitation affects window switchers, screen readers and automation tools.
| Application family | Typical behaviour | What helps |
|---|---|---|
| Electron apps (Slack, Discord, VS Code, Notion) | Intermittent; usually fine, occasionally goes silent | Restart the app; it almost always clears |
| Microsoft Office | Frequent greying, especially Outlook | Restart the app; consider excluding it from double-click actions |
| Java-based tools (some IDEs, older enterprise apps) | Non-standard window objects | Often permanent; position manually |
| Adobe After Effects | Main window is not a real macOS window | Cannot be fixed externally; a known upstream limitation |
| Virtual machines and remote desktop | Guest draws its own interior | Position the host window instead |
| Anything in native full screen | Occupies its own Space, not an ordinary window | Exit full screen first |
The pattern is consistent: applications that draw their own window chrome rather than using native macOS windows are the ones that break. Restarting the offending application resolves the transient cases, which is most of them.
An application in native full screen is not a resizable window — macOS has moved it to its own Space. Every window manager will show greyed-out commands for it. Use the maximise command instead if you want a full-screen appearance that stays snappable.
Reading the log properly
Hold ⌥ Option with the menu open and choose View Logging…. Then reproduce the problem. The log distinguishes the two causes clearly.
A successful command prints the geometry it applied. A failed one prints the element error. If you see success lines for some applications and failures for others in the same session, the permission is fine and you are looking at cause B. If every line is a failure, you are looking at cause A.
Living with applications that will not cooperate
For an application that fails permanently rather than transiently, there is no workaround that makes it obey shortcuts. What is available:
- Position it manually once and build the rest of the layout around it. Most such apps do remember their own geometry between launches.
- Use the application's own window management if it has any — several Java IDEs and Adobe tools have internal layout systems that work fine.
- Where the app has both a native and a web version, the native one is sometimes better behaved. Occasionally the reverse is true.
- Report it to the application's developer, not to the window manager's. The missing accessibility support is on their side, and it also breaks screen readers, which is usually a more persuasive argument.
It is worth stating plainly: this class of problem is not something the Rectangle project can fix. macOS offers exactly one mechanism for external window control, and an app that does not implement it is invisible to every tool that uses it.
Get the current build
Rectangle is free and open source. Everything documented here works in the standard build.
Download from rectangleapp.comThe Chrome performance footnote
A related and frequently misdiagnosed effect: granting Accessibility permission to any window manager causes Chrome and Chromium-based browsers to enable their internal accessibility subsystem. On pages with very large DOMs this has a measurable performance cost, and people notice the slowdown appearing at the same time as they installed a window manager.
The cause is real, but it is a Chromium design decision rather than a defect in the window manager — Chromium turns on full web accessibility whenever any assistive client is present, without distinguishing between a screen reader and a tool that only wants window geometry. There is a separate guide covering the mitigations.
Questions
Why does it only happen with Slack?
Electron applications intermittently stop answering accessibility requests. Restarting the app clears it; there is no permanent fix from outside.
Is greyed out the same as the app being broken?
No. It means the frontmost window cannot be read. Click a native app like Finder — if the menu enables, everything is working correctly.
Can I force a window to move anyway?
No. Without an accessibility element there is no object to write a new position to.
Does restarting the Mac help?
Only for the permission cause. For app-specific cases, restarting the offending application is faster and more reliable.