Repository navigation
macos: honor window-save-state=never for restorable windows - #14506
Merged
bo2themax merged 3 commits intoOct 2, 2026
Merged
Conversation
Normal terminal windows remain eligible for native AppKit restoration when window-save-state is never, allowing background window snapshots to contend with window updates. Apply the setting when creating a terminal window and assign its restoration class and identifier only when restoration is enabled.
Contributor
Author
BarutSRB
force-pushed
the
fix-macos-window-save-state-never
branch
from
October 1, 2026 20:35
c86bd50 to
1360297
Compare
Member
Is there a reason why it's not updated after reload?
Please be cautious about this in the future, the PR description should be written by HOOMAN. |
Contributor
Author
|
@bo2themax Hey, sorry for the non HOOMAN 😂 PR description, had so many scattered notes for it that I just fed it to organize it as I was on a break and used my phone. As for not updating exsisting windows, you are right, pushing soon the follow up commit. |
Existing terminal windows retained their creation-time restoration policy after configuration changes. Refresh that policy on global config reload and share setup with window creation, preserving the custom-command exclusion.
bo2themax
requested changes
Oct 2, 2026
bo2themax
left a comment
bo2themax
left a comment
Member
There was a problem hiding this comment.
One suggestion, also the tests seems unnecessary and potentially flaky. Accessing UI stuff in the UnitTest is not that reliable.
Let isRestorable control preservation while assigning the restoration class and identifier consistently for every terminal window. Remove the restoration test fixture that creates AppKit windows and broadcasts configuration changes through the shared test host.
bo2themax
approved these changes
Oct 2, 2026
Contributor
Author
|
Thank you |
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
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.
With
window-save-state = never, normal terminal windows are still markedisRestorable. Ghostty disables saving throughNSQuitAlwaysKeepsWindows, but AppKit continued taking persistent-UI window snapshots in my reproduction on macOS 27.2 (26B5091g).Make
TerminalController.windowDidLoad()also honorneverwhen settingwindow.isRestorable, and only assign the restoration class and identifier when that flag is enabled. This adds no work to move, resize, or rendering callbacks.For newly created windows,
defaultandalwaysretain the existing behavior, including the exclusion of windows launched with a custom command. The follow-up commit also covers windows that are already open: on config reload, each terminal window re-syncs its restoration state through the same path used at window creation. Windows started with a custom command stay excluded.Reproduction and measurements
I reproduced intermittent roughly 500 ms stalls while repeatedly focusing left/right between several Ghostty windows and other applications in OmniWM's Niri layout.
window-save-state = neverwas set before restarting Ghostty.The issue reproduced on 1.3.1 and an unmodified build of
76895d97b. In the latter, paired process samples showedNSPersistentUIWindowSnapshotterwaiting throughSLSConnectionSynchronizeSLSCATransaction, alongside Ghostty's main thread waiting on the connection lock underSLSConnectionSetLastSLSCATransaction.Comparing unmodified and patched builds of the same commit over two approximately 20-second navigation captures:
The persistent-UI snapshot worker was absent from the patched sample, and navigation feels noticeably smoother. These are aggregate samples from one before/after pair with different input counts, not a controlled end-to-end latency benchmark. Both Ghostty builds used ReleaseLocal with the same ReleaseFast core, while OmniWM remained the same instrumented Debug process.
Validation
macos/build.nu --action test: 275 passed, 1 skipped, 0 failed.macos/Tests/Terminal/TerminalControllerRestorationTests.swift: reload flips restoration on an open window betweennever,defaultandalways; custom-command windows stay non-restorable across reloads; surface-level config changes leave it alone.macos/build.nu --configuration ReleaseLocal: passed.AI disclosure
I used OpenAI Codex to assist with diagnosis, implement the two-line change, run verification, analyze the captures, and draft this description. I reproduced the issue and tested the patched app interactively.