Why Rectangle’s Windows Aren’t Perfectly Flush (And When That’s Fixed)

A specific class of complaint shows up repeatedly about Rectangle app: a window that should be perfectly maximized or exactly half the screen instead has a thin, visible gap somewhere — usually near the menu bar or between two supposedly adjacent windows. Some of this is an intentional setting; some of it is a real, reported bug; and some of it has already been fixed in recent versions.

First: check if you have a gap setting enabled

Rectangle mac supports an intentional pixel gap between tiled windows and screen edges, set through Terminal commands (gapSize, or the more granular snapEdgeMarginTop/Bottom/Left/Right). If you or a setup guide you followed enabled this at some point, a visible gap is expected behavior, not a bug. Check your current values:

defaults read com.knollsoft.Rectangle gapSize

If this returns a non-zero number, that’s your answer. Remove it with:

defaults delete com.knollsoft.Rectangle gapSize

and restart Rectangle app.

A genuinely reported bug: gap specifically at the top edge

Issue #1554 describes a 1-pixel gap appearing specifically between the top of a maximized window and the menu bar, with no gap setting intentionally configured. Issue #1347, filed separately, describes something related but more pronounced: with a gap setting enabled, the gap at the top of the screen measured roughly 20% larger than the identical gap setting produced on the left, right, and bottom edges — an inconsistency specifically at the top, not a general gap-sizing bug. Both point to the same general area of the code (how Rectangle app calculates the boundary near the menu bar) rather than to a setting you can toggle away.

If you’re seeing a small, consistent gap specifically at the top of maximized or top-half windows and nowhere else, this is a known category of report rather than something misconfigured on your end — check the current status of these issues, since gap-calculation code is exactly the kind of thing that gets refined across point releases.

Negative gaps not behaving as expected

Issue #576 describes a more specific case: setting a negative value for screenEdgeGapBottom (intended to let a maximized window extend slightly past the visible screen edge, hiding a sliver off-screen) didn’t have any effect — the window maximized as if the gap were zero, while the equivalent positive gap value worked correctly. If you’re trying to use a negative gap value for this specific effect and it’s not doing anything, this is a documented report of that exact behavior not working as expected, not a syntax error in your command.

A fix that’s already shipped: clamped windows leaving unwanted gaps

Version 0.97‘s release notes specifically address a related but distinct problem: windows that are clamped (prevented from reaching their full calculated size, typically because of a minimum-size constraint the app itself enforces — the same category of issue covered when discussing apps like Discord or Spotify) used to be left floating with a gap between the window and the snap edge, rather than being pushed flush against it. The v0.97 changelog lists «Anchor clamped windows to the snap edge instead of leaving a gap» and «Align clamped windows to snap edges by default» as specific fixes for this. If you were seeing a gap specifically on windows that also seem reluctant to shrink fully — the Discord/Spotify-style problem — and you’re running a version older than 0.97, updating may resolve the gap specifically, even though it won’t remove the app’s underlying minimum-size limit.

The half-split ratio and corner actions

The same v0.97 release also «applies Half-Split ratio to corner actions and snap areas» — a fix aimed at consistency between how a plain half-screen action divides the screen and how a corner or snap-area action divides it, addressing a case where those two paths could previously produce slightly different boundary calculations for what should be the identical split point.

How to check whether your specific gap is already fixed

1. Check your current Rectangle app version (menu bar icon → About, without holding Option).
2. Compare it against the version each fix above shipped in — v0.97 for the clamped-window anchoring fix, and check the current status of the top-edge-gap issues (#1554, #1347) directly, since they may have been resolved in a version after this article was written.
3. If you’re behind, update first before assuming a specific complaint is a persistent, unfixable issue — several of the gap-related reports on the tracker were closed by point releases addressing the exact calculation involved.

When it’s genuinely not a bug

A gap that appears only in one specific app and nowhere else is more likely the app’s own minimum-size behavior (covered in detail elsewhere in this series for apps like Discord, Spotify, and terminal emulators) than a Rectangle-side pixel calculation bug. The distinguishing test is the same one used throughout this series: if the same action produces a clean, flush result in most apps and only misbehaves in one specific app, the app is the variable. If the gap appears consistently across every app at the same screen edge, that points toward Rectangle’s own edge-calculation code, and it’s worth checking the specific issues above or filing a new one with your macOS and Rectangle version if it isn’t already reported.