Skip to content

Fix Open in Terminal doing nothing in released builds - #638

Merged
hannesa2 merged 1 commit into
gitx:masterfrom
goneng:add-apple-events-entitlement
Sep 15, 2026
Merged

Fix Open in Terminal doing nothing in released builds#638
hannesa2 merged 1 commit into
gitx:masterfrom
goneng:add-apple-events-entitlement

Conversation

@goneng

@goneng goneng commented Sep 13, 2026

Copy link
Copy Markdown
Collaborator

Opening a repository in a terminal is carried entirely by an Apple event, which
the hardened runtime refuses to send unless the application asks for the
privilege. Released builds are signed with that runtime and an empty
entitlements file, so Repository > Open in Terminal launches the terminal and
then silently drops the command that was supposed to cd into the repository.

Fixes #636, where the diagnosis is written up in full.

Changes

  • Declare com.apple.security.automation.apple-events in GitX.entitlements,
    so the event reaches Terminal or iTerm2 instead of being rejected with
    errAEEventNotPermitted (-1743) below the consent layer, where it produces
    neither a prompt nor an entry in Privacy & Security > Automation.
  • Add PBGitXEntitlementsTests, asserting the running application carries the
    entitlement. Worth guarding, because com.apple.security.get-task-allow
    lifts the same restriction for locally built copies: the feature works when
    built from Xcode and fails only in the shipped app, which is how this
    survived since at least fails to open console in the current directory #460.
  • Link Security.framework into the test target, which SecTask needs.

Test plan

  • make unit-test fails on the new test before the entitlement is added
    (GitX cannot drive a terminal application without this entitlement) and
    passes after it, 106 tests green.
  • codesign -d --entitlements - on the built app shows the key in the
    signature.
  • Measured separately on a minimal app bundle, re-signed three ways and rerun
    unchanged: -o runtime with no entitlements gives -1743 and no prompt,
    -o runtime plus this entitlement succeeds, and -o runtime plus
    get-task-allow also succeeds.

Note that Resources/GitX.entitlements is a second, unreferenced copy of this
file, still empty. CODE_SIGN_ENTITLEMENTS points at the one in the project
root, so it is left alone here.

@goneng
goneng marked this pull request as ready for review September 13, 2026 22:09
@goneng goneng added the bugfix label Sep 13, 2026
@hannesa2

hannesa2 commented Sep 14, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

I don't see the issue on recent brew version and can't reproduce the issue with this change.
Any idea ?

trim image

@goneng

goneng commented Sep 14, 2026

Copy link
Copy Markdown
Collaborator Author

Thanks for testing it. I could not get your result here, so I measured the
shipped artifact directly rather than a local build.

I downloaded GitX-arm64.dmg from the 1.5.7 release and copied the app out of
it (spctl -a -vvv reports accepted, source=Notarized Developer ID), opened
a repository in it, and clicked Repository > Open in Terminal with Terminal not
running:

  • Terminal launched, so the menu action definitely ran. PBTerminalUtil hands
    the target to SBApplication, which launches it through LaunchServices
    before the event is sent.
  • The window that appeared was a plain login shell with cwd /Users/gonen, not
    the repository. The cd "<repo>"; clear; echo '# Opened by GitX'; git status
    that doScript carries never arrived.

So the released build does drop the command, on a machine where it had never
run before.

One thing makes our two observations hard to compare: the About box cannot tell
a release from a local build. That string is git describe plus git rev-parse --abbrev-ref HEAD, and HEAD there only means a detached checkout, which is
what CI does when it builds a tag and also what you get from git checkout 1.5.7. Both produce exactly 1.5.7-HEAD (1.5.7.3230 [arm]), so your
screenshot matches the release without confirming it.

Could you run this against the app you tested?

codesign -dvvv /Applications/GitX.app 2>&1 | grep -E "Authority|flags="

The release answers Authority=Developer ID Application: Farhan Ahmed (4RZN52RN5P) with flags=0x10000(runtime). A local build answers Apple Development or ad-hoc, and a Debug build carries no runtime flag at all, since
80deb7b removed it from that configuration. A Debug build can always send the
event, which is the trap this PR is about.

Worth ruling out one more thing: your recording shows no consent dialog, so
that machine already holds an Automation grant for GitX, where mine held none.
If your copy does turn out to be the release, then

tccutil reset AppleEvents net.phere.GitX

and retrying would tell us whether an existing grant is what carries it
through. If it is, the entitlement only matters to people who have never
granted it, and the issue text needs narrowing.

Unrelated aside: do not test with the .zip asset. It is packaged with zip -r, which drops the frameworks' symlinks, so macOS rejects it as damaged.
#649 fixes that.

@goneng
goneng force-pushed the add-apple-events-entitlement branch 2 times, most recently from cf85b3c to 6274dff Compare September 15, 2026 06:46
@goneng

goneng commented Sep 15, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

@hannesa2 whenever you have a moment, could you run the two commands from my comment above?
This should show whether the copy you tested was the release build or a local one and help explain why our results differ.
Thanks!

@hannesa2

hannesa2 commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

Now I use
image

These are the two commands
image

But now the "open in terminal" just opens previous terminal and not the right directory.

I would merge it now, but as it comes with a conflict, I'll wait till is solved

@goneng Gonen
Fix Open in Terminal doing nothing in released builds (issue gitx#636)
b762deb 
Opening a repository in a terminal is carried entirely by an Apple event,
which the hardened runtime refuses to send unless the application asks for
the privilege.

* Declare com.apple.security.automation.apple-events, so the command
  reaches Terminal or iTerm2 instead of being rejected below the consent
  layer, where it produces neither a prompt nor an error.
* Cover the entitlement with a test. The restriction is lifted for local
  builds by com.apple.security.get-task-allow, so the failure never shows
  up when building from Xcode and needs guarding rather than noticing.
* Link Security.framework into the test target, which the check needs.
@goneng
goneng force-pushed the add-apple-events-entitlement branch from 6274dff to b762deb Compare September 15, 2026 15:12
@goneng

goneng commented Sep 15, 2026

Copy link
Copy Markdown
Collaborator Author

I would merge it now, but as it comes with a conflict, I'll wait till is solved

sure - I've rebased it now - should pass the CI-tests soon, thanks

@hannesa2
hannesa2 merged commit 583def9 into gitx:master Sep 15, 2026
3 checks passed
@goneng
goneng deleted the add-apple-events-entitlement branch September 15, 2026 18:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

bugfix

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Open in Terminal opens Terminal without cd-ing to the repository

2 participants

@goneng @hannesa2