Skip to content

fix: keep panes alive when an app launched from one is force-quit (INC-384) - #502

Merged
arzafran merged 2 commits into
mainfrom
fix/inc-384-force-quit-panes
Oct 29, 2026
Merged

arzafran merged 2 commits into
mainfrom
fix/inc-384-force-quit-panes

Conversation

@arzafran

Copy link
Copy Markdown
Member

Force quitting an app launched from a Programa pane (from the Dock) used to kill Programa and every pane. macOS counted every pane process as part of Programa, so it took them all down together.

Pane commands now start as their own "responsible process", using the same private macOS call iTerm2 uses, with an execve fallback. The submodule bump (ghostty 7e4b75eef) carries the change, and docs/ghostty-fork.md has a new section 13 describing it.

Checked by hand on a tagged build. Before the fix, force quitting a test app launched from a pane killed the app, both panes and their sleep processes. After it, only the test app died.

One visible side effect: panes no longer inherit Programa's privacy permissions. The first time a pane reads ~/Desktop, ~/Documents or ~/Downloads, macOS shows a permission prompt (confirmed). This ships always on, by decision.

The GhosttyKit checksum for the new SHA is added in a follow-up commit once the build-ghosttykit workflow publishes the asset, so macOS CI will fail until then.

Fixes INC-384

@arzafran
arzafran merged commit e77a9c5 into main Oct 29, 2026
13 checks passed
@arzafran
arzafran deleted the fix/inc-384-force-quit-panes branch October 29, 2026 19:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant