fix(macos): do not prefer tabs when opening documents - #4
Merged
Conversation
New windows opened from the AeroSpace keybindings (alt-enter for the terminal, alt-w for the browser) land in the workspace where that app's first window was created rather than the focused one, and macOS switches you there. Not a configuration error: it is a known AeroSpace issue (nikitabobko/AeroSpace#1929) that reproduces on a default config, and the maintainer cannot reproduce it. The only mitigation suggested in that thread is turning off macOS's preference for tabs, which is what this sets. AppleWindowTabbingMode was unset, so it took the macOS default of "fullscreen". Under that setting an app prefers reusing an existing window to creating a new one, which is the behaviour the window manager then has to chase. Ruled out while diagnosing: no other window manager is running, and all eight on-window-detected rules are `layout floating` for Apple utilities, none of which match Ghostty or Helium.
alt-w put new browser windows in whatever workspace Helium was last used in, and switched macOS there. alt-enter never had the problem, and the difference was the mechanism rather than anything workspace-related. `open -na "Helium"` asks macOS for a new *instance*. Helium is Chromium based and Chromium is single-instance, so the new process found the running one, handed the request to it and exited. macOS then activated that existing instance, which lives wherever it was last used, and the window opened there. alt-w now drives the running process's own File > New Window through System Events, which is exactly what alt-enter does for Ghostty and why that one has always landed in the right place. Falls back to activating the app when it is not already running. This is separate from AeroSpace#1929, the unresolved upstream issue also mitigated in this branch; that one reproduces on a default config, whereas this was self-inflicted by the binding.
ptaranat
added a commit
that referenced
this pull request
Jul 31, 2026
Mitigation for new windows opening in the wrong AeroSpace workspace. `AppleWindowTabbingMode` was unset, defaulting to `fullscreen`, under which macOS prefers reusing an existing window over creating a new one. Set to `manual`. Known upstream issue: nikitabobko/AeroSpace#1929. Unresolved, maintainer cannot reproduce, reproduces on default config. This is the only mitigation suggested in that thread, so it may not fix it. Ruled out: no competing window manager; all 8 `on-window-detected` rules are `layout floating` for Apple utilities and match neither Ghostty nor Helium.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Mitigation for new windows opening in the wrong AeroSpace workspace.
AppleWindowTabbingModewas unset, defaulting tofullscreen, under which macOS prefers reusing an existing window over creating a new one. Set tomanual.Known upstream issue: nikitabobko/AeroSpace#1929. Unresolved, maintainer cannot reproduce, reproduces on default config. This is the only mitigation suggested in that thread, so it may not fix it.
Ruled out: no competing window manager; all 8
on-window-detectedrules arelayout floatingfor Apple utilities and match neither Ghostty nor Helium.