Repeated prompts to install helper on macOS Monterey

[obchodniuspech]

Describe the bug

Every hour or two, Github desktop asks me for installing support tools....

Version & OS

Mac Os X Monterey
Github Desktop - Version 2.9.6 (arm64)

Open the 'About GitHub Desktop' menu to see the GitHub Desktop version. Also include what operating system you are using.

Steps to reproduce the behavior

Have open app in the background.

Expected behavior

Install the most once a week probably?

Actual behavior

Write a clear and concise description of what actually happened.

Screenshots

https://cln.sh/GS2vj7

Logs

2022-02-18T01:14:47.995Z - info: [ui] Executing getStatus: git --no-optional-locks status --untracked-files=all --branch --porcelain=2 -z (took 1.334s)
2022-02-18T10:09:39.385Z - info: [ui] Executing fetch: git -c credential.helper= -c protocol.version=2 fetch --progress --prune origin (took 3.814s)
2022-02-18T10:12:21.435Z - info: [ui] [BranchPruner] Last prune took place in 13 hours - skipping
2022-02-18T11:51:47.171Z - info: [ui] Executing fetch: git -c credential.helper= -c protocol.version=2 fetch --progress --prune origin (took 3.795s)
2022-02-18T14:12:24.413Z - info: [ui] [BranchPruner] Last prune took place in 9 hours - skipping
2022-02-18T15:18:43.319Z - info: [ui] Executing fetch: git -c credential.helper= -c protocol.version=2 fetch --progress --prune origin (took 3.060s)
2022-02-18T18:10:17.997Z - info: [ui] Executing fetch: git -c credential.helper= -c protocol.version=2 fetch --progress --prune origin (took 1.219s)
2022-02-18T18:12:29.026Z - info: [ui] [BranchPruner] Last prune took place in 4 hours - skipping
2022-02-18T19:52:57.005Z - info: [ui] Executing fetch: git -c credential.helper= -c protocol.version=2 fetch --progress --prune origin (took 1.046s)
2022-02-18T21:02:01.106Z - info: [ui] Executing fetch: git -c credential.helper= -c protocol.version=2 fetch --progress --prune origin (took 4.035s)
2022-02-18T22:12:22.753Z - info: [ui] [BranchPruner] Last prune took place in 30 minutes - skipping

2022-02-20T12:14:05.764Z - info: [ui] [BranchPruner] No branches to prune.
2022-02-20T12:14:08.282Z - info: [ui] Executing getStatus: git --no-optional-locks status --untracked-files=all --branch --porcelain=2 -z (took 1.199s)
2022-02-20T12:22:02.923Z - info: [ui] Executing getStatus: git --no-optional-locks status --untracked-files=all --branch --porcelain=2 -z (took 1.118s)
2022-02-20T12:22:08.231Z - info: [ui] Executing getStatus: git --no-optional-locks status --untracked-files=all --branch --porcelain=2 -z (took 4.646s)
2022-02-20T12:22:08.794Z - info: [ui] [RepositoryIndicatorUpdater]: Refreshing sidebar indicators for 13 repositories took 12.9s of which 470.3s paused, total 483.2s

[sergiou87]

Thanks for your report @obchodniuspech

I don't exactly understand why it's asking for your password 🤔 We have released 3 new versions this week (2.9.7, 2.9.8 and 2.9.9) to address a few issues we've found, not sure if those many releases is why Desktop is bugging you.

Could you upgrade to the latest version and see if it still requests your password?

[obchodniuspech]

I just upgraded, it could leave me in peace for about 3 days and then when Iam working on project it asks for example 30 times in one afternoon :D its very scary and I event wanted to uninstall completely :D I will try the new version. I hope it will dissapear its very anoing :(

[obchodniuspech]

Its happening again. Are there more helping tools for github or only one? What can I do for better debugging?

[sergiou87]

There are no "tools", I'm not totally sure why it's prompting you the password so many times, other than to get access to your GitHub token (to keep you signed in). In the screenshot you shared the dialog says "there is an update ready to install", which shouldn't require admin permissions 🤔

Is the app correctly located in /Applications?

[obchodniuspech]

It says it want to install helper tool and update :D

Yes, the app is in /Applications

If its only my problem Im not sure what to do I will try to reinstall, when I will finish project Im working on cause Im too lazy to fill in the auths again :D

[obchodniuspech]

just to let you know, on actual version it asks - like 4-6 times a day... kill me :D

[eaglesongs]

I have this same problem, and it was happening even before I upgraded to Monterey. In fact, it just happened when I was trying to sign in to leave this comment, and I had to enter my password 4 times in a row before it finally stopped! This is maddening!

[ColeDCrawford]

Also get this, most frequently with Github but also some other apps.

[hliljegren]

Just want to chime in as I have the exact same issue. Github desktop is installed in /Applications but (for security reasons) I'm not normally logged in as admin and thus normally needs to enter admin user and password to write to the /Applications folder if that can make any difference. I also have two git accounts one for work and one private, if that can give any clues. I'm on an intel mac with MacOS 12.3.1 (Monteray)

[amcgregor]

I get the prompt a minimum of three times after returning to my workstation after an extended period of time, i.e. a work day.

These prompts don't actually say anything about the operation underway, and I reject them. A software update is not a helper application being installed, making it sufficiently suspicious. If I do bother with the dance in a VM, I'm asked a minimum of three times.

Git on my machine is managed by Homebrew, I do not require (nor desire) graphical applications manipulating the contents of /usr/local… if that's even what it's doing. Edit to note: at least this isn't quite as bad as #1128. This is occasionally annoying, repeated polling with a hardware token was a several-times-per-hour affair. Edit to edit to note a second note: the GitHub Desktop.app bundle is also located in a shared area—/Users/Shared/Applications/Development—with full write permission for the active user. It's really not attempting to update the app bundle. For me, this is something else.

[sergiou87]

As mentioned before, GitHub Desktop shouldn't install any kind of tool… I'd only expect it to prompt for your macOS user password to read your GH token from the keychain. Also, GitHub Desktop bundles its own git but it's not available broadly, it's used only by GH Desktop. However, this is interesting:

the GitHub Desktop.app bundle is also located in a shared area—/Users/Shared/Applications/Development

Could you try installing it "normally" to /Applications and see if it still behaves the same way?

[eaglesongs]

Mine is installed in /Applications, and I still get this prompt all the time.

[hliljegren]

Mine is installed in /Applications, and I still get this prompt all the time.

Mine too!

[amcgregor]

Interesting note to add, even if it were attempting to install a utility helper under /usr/local, e.g. linking its own git under /usr/local/bin (which it must not, that's Xcode-managed via "Command Line Build Tools" package installation) or installing a github command (which it doesn't), it would not require administrative permissions to do so. /usr/local is owned by my user account due to the use of Homebrew package management.

The prompt seems fairly clear to me that this isn't a Sparkle (automatic) update being applied. "Add a new helper tool" may be overly generic, though. Edit to add: and it's very insistent. Back to only having it running when actively in use—just like before the option to disable automatic fetch—I guess.

Edit again: it really doesn't seem related to update installation. This morning I got the banner that an update was downloaded and ready to install, click to restart the app. After days of cancelling the sudo prompts. Clicked, it restarted, and was updated.

[aussiemate32]

I too have this problem.. it makes GitHub desktop unusable..

[amcgregor]

As mentioned before, GitHub Desktop shouldn't install any kind of tool… I'd only expect it to prompt for your macOS user password to read your GH token from the keychain. Also, GitHub Desktop bundles its own git but it's not available broadly, it's used only by GH Desktop. However, this is interesting:

the GitHub Desktop.app bundle is also located in a shared area—/Users/Shared/Applications/Development

Could you try installing it "normally" to /Applications and see if it still behaves the same way?

I have an office workstation and a home one. The provided description was from home, remains true at the office where GitHub Desktop.app is installed in /Applications, a location I do not generally have write access to. Same situation; came into the office this morning, there was the "an update has been downloaded, restart GitHub Desktop" notice, restarted and updated fine—with no sudo prompts.

I think the really fundamental question is: what the ████ is it doing requiring these prompts? I'm security-conscious (totally not an IT specialty), so unexpected prompts like these are serious warning flags. One of the security tools I use had a Sparkle update that failed to render all text on window widgets, I did not even attempt to permit it (outside an ephemeral sandbox VM) before confirming with the vendor that this was a known bug, and the update was legitimate.

Edit: Here's that tweet about the blank Sparkle update.

[sergiou87]

Thank you all for your feedback 🙇

@amcgregor again, AFAIK GitHub Desktop should prompt for anything unless you choose to install the CLI tool from GitHub Desktop -> Install Command Line Tool… but you would know in that case, so we have no idea where that prompt comes from. We don't use Sparkle for updates, we use Squirrel, which is what Electron uses.

Doing some search on Google, I see other people having the same prompt with other Electron apps like Slack, and changing the permissions of the /Applications/Whatever.app helped: https://apple.stackexchange.com/a/271123

In my case, it looks like this:

drwxr-xr-x@ 3 sergiou87  staff   96 Mar 18 14:16 GitHub Desktop.app

Could that be the issue you're facing?

[amcgregor]

@sergiou87 Interesting; the @ in the permissions summary says there are XATTR ACLs present; the "UNIX permissions" don't tell the whole story in your case. It's also seemingly owned by you.

At my office station, owned by the domain administrator's local representation:

drwxr-xr-x   3 localadmin  staff    96B 26 Apr 04:16 /Applications/GitHub Desktop.app

Neither has XATTRs; at home:

drwxr-xr-x   3 root       wheel    96B 20 Apr 06:36 /Users/Shared/Applications/Development/GitHub Desktop.app

This is, admittedly, quite strange. I'll blame the Migration Assistant on this one. ("Must quit all applications" is often code for "we're dropping down to a console session as root".) When I get home, I'll tweak these permissions and see if it makes a difference. Thanks for the pointer!

(Pardon the edits; deep paths, man, and keeping the fenced blocks understandable. Self-modifying applications—requiring write permission to themselves—unrelated to software updates are another warning sign.)

[sergiou87]

No worries, we're really grateful for all the detailed research you're doing!! As we were unable to reproduce this, we were completely clueless 😖

[amcgregor]

Found it. This appears (since I hit "record" after the prompt appeared…) when I cancel the prompt:

Failed to authorize right 'com.apple.ServiceManagement.daemons.modify' by client \
 '/Users/Shared/Applications/Development/GitHub Desktop.app' [58319] for authorization \
 created by '/Users/Shared/Applications/Development/GitHub Desktop.app' \
 [58319] (3,0) (-60006) (engine 704)

Backslashes added by me; originally a single line. I've now updated the permissions on-disk:

sudo chown -R ${USER}:staff /Users/Shared/Applications/Development/GitHub\ Desktop.app
chmod -R g+w /Users/Shared/Applications/Development/GitHub\ Desktop.app

Group write enforced because I do actually want any user of the system able to update the application in a shared home folder overlay. Now to wait and see if the prompt re-appears or additional console output is detected relating to GitHub.

My next step if this fails would have to be to attempt to apply custom XAttr ACLs (i.e. grant each user permission explicitly) or ultimately moving the application to a volume with "ignore owners" set as a failsafe.

Does anyone have advice for multiuser environment deployments? [a few minutes later] And I notice no option to disable automatic updates, so no centralization of that task and elimination of the local periodic check.

Edit to add: I did notice the file it was attempting to write to was deeply nested within the bundle, but failed to capture the exact path.

[amcgregor]

And I can confirm permissions were my issue:

Download completed to: file:///…/Library/Caches/com.github.GitHubClient.ShipIt/update.HcQY5q8/GitHubDesktop-x64.zip
powerd	Created PreventSystemSleep "Preparing update" age:00:00:00  id:30064813935 [System: PrevIdle PrevSleep DeclUser BGTask kCPU kDisp]
Claim 28E6AACE-441B-4BBF-AA83-89959432B814 granted in client
Claim 28E6AACE-441B-4BBF-AA83-89959432B814 invoked in client
Process GitHub Desktop.62205 Released PreventSystemSleep "Preparing update"

This notice appears important:

kernel	AMFI: …/GitHub Desktop.app/Contents/Frameworks/Squirrel.framework/Versions/A/Resources/ShipIt \
doesn't have DER entitlements and **will not work in a future release**

Asterisks mine. 😉 It continues:

ShipIt	Detected this as an install request
ShipIt	Read options: 80000001 -- URL: <private> -- purposeID: 8FD94BFA-3BF0-4EB1-B2CA-AE87AF1909FC -- claimID: C1D2F485-DE97-4601-A6F5-F185745C1694
ShipIt	Claim C1D2F485-DE97-4601-A6F5-F185745C1694 granted in client
ShipIt	Claim C1D2F485-DE97-4601-A6F5-F185745C1694 invoked in client
ShipIt	Received configuration update from daemon (initial)

This is all fairly cleaned up, and after this there's a good chunk of tccd network-related chatter; state change notifications and whatnot. But notably: no "installing a helper tool" prompt.

🧈🥬💃

[sergiou87]

Yay! Thanks again for your detailed reports 🙇‍♂️

@obchodniuspech I hope this helps you too: you must make sure all files in /Application/GitHub Desktop.app/ are owned by your user.

Closing now…

[obchodniuspech]

Im not sure, if i did it right, but i added myself and added rights to write and read. But it didnt help... after like 4 hours window showed up again..


.

[sergiou87]

@obchodniuspech could you run ls -l /Applications | grep Desktop to see what the permissions are for GitHub Desktop?

You should see something like this:

$ ls -l /Applications/ | grep Desktop
drwxr-xr-x@ 3 sergiou87  staff   96 Mar 18 14:16 GitHub Desktop.app

[aussiemate32]

Has the installer been updated to prevent this happening? Or instructions on how to install without this problem occurring? I found on 2 machines using the installer created this problem.

[sergiou87]

@aussiemate32 I have no idea how this could happen to begin with 🤔 The first time a user installs this is by unpacking a zip and moving the GitHub Desktop.app bundle to /Applications, and after that it would auto-update to new versions by automatically doing that same process.

Did you install it differently? I wonder what the difference actually was… 🤔

[obchodniuspech]

ls -l /Applications/ | grep Desktop
drwxr-xr-x+ 3 root wheel 96 17 úno 18:28 GitHub Desktop.app

[sergiou87]

@obchodniuspech thank you. As you see, root is the owner, which I think is the cause of your problem.

How did you install GitHub Desktop exactly? I wonder if just deleting it entirely, and then downloading the latest version from https://desktop.github.com/ and installing it again would solve the issue.

[amcgregor]

ls -l /Applications/ | grep Desktop
drwxr-xr-x+ 3 root wheel 96 17 úno 18:28 GitHub Desktop.app

@obchodniuspech Have you restored your machine using Migration Assistant, by any chance?

[obchodniuspech]

@amcgregor if you mean like when iam buying new mac, sure - i do this all the time. I dont have any other problems with other apps.

[aussiemate32]

@aussiemate32 I have no idea how this could happen to begin with 🤔 The first time a user installs this is by unpacking a zip and moving the GitHub Desktop.app bundle to /Applications, and after that it would auto-update to new versions by automatically doing that same process.

Did you install it differently? I wonder what the difference actually was… 🤔

I’m very new to GitHub. apologies I thought I’d installed it from an installer.. dmg type thingy.. I still have no idea how this happens..

[amcgregor]

@amcgregor if you mean like when iam buying new mac, sure - i do this all the time.

Cool. That was the exact reason why my GitHub Desktop.app did not have correct permissions. I completely reinstalled and restored my home workstation using Migration Assistant a few weeks ago, and at the office, my domain administrator owns the files. In both cases, the file ownership and permissions were the cause of the prompts; see above.

I dont have any other problems with other apps.

It's very rare for an application to be self-modifying in this way. Most update systems notify of an update and request permission to install ("install now", "install on next start", &c.) thus give a clear indication of why a sudo (elevated permissions) prompt may appear. If the application being updated is not owned by your user account, clicking "update now" will immediately prompt for elevated permissions with a clear correlation and explanation for why you are being prompted. Most wouldn't think about it as being unusual in this type of case—often I don't even notice it for updates to things like my DBA tools or multimedia software.

It's unusual in GitHub Desktop's case in that it attempts to silently write to its own internal files, triggering the prompt seemingly without reason. No "would you like to update now, or later" prompt which would give an indication as to the action underway which would require this.

No way to disable automatic modification at all. (My domain administrator is not particularly happy about this fact.)

Im not sure, if i did it right, but i added myself and added rights to write and read. But it didnt help... @obchodniuspech

That was going to be one of my next steps. What you did was add your user account as an ACL (Access Control List) entry. I'm not entirely sure this permission gets inherited on files deeper within the bundle; try changing the owner instead: (this corrected the issue for me, though I did this from Terminal, not Finder)

[leonidmakarovsky]

Hello, I have the same problem on Monterey 12.4. Is there a fix for that?

[literallylara]

I have the same problem on Montery 12.5.1, but it also existed many versions before that.
In my case I believe the issue is caused by having two admin accounts set up (one personal, one for work):

$ groups lara
> staff admin ...

$ groups work
> staff admin ...

Before updating, I did:

$ sudo chown -R root:admin GitHub\ Desktop.app
$ sudo chmod -R 775 GitHub\ Desktop.app

Which results in:

$ ls -l /Applications
> ... 
> drwxrwxr-x   3 root  admin    96 Aug 24 10:11 GitHub Desktop.app
> ...

I then proceeded to update the app via the Work user, which worked fine without any prompts, but it changed the ownership and permission:

$ ls -l /Applications
> ... 
> drwxr-xr-x   3 Work  staff    96 Aug 24 10:11 GitHub Desktop.app
> ...

This again leaves me with the problem that I will only be able to update the app without prompts from the Work account. As soon as I switch to my personal account the helper tool prompts will appear again. I also tried setting the user and group to Work:staff with g+w permissions as suggested in another comment above but after updating the g+w permission disappears again.

I should note that the exact same behaviour can be observed with other Electron-based apps, like Visual Studio Code. I wonder if this can be fixed with ACL permissions, or if the solution is just to install every app twice. Any help would be appreciated.. :)

[amcgregor]

While I appreciate that in single-user environments the problem appears to be less of a problem, the problem still exists, especially for managed workstations. The update mechanism is not transactional and attempts to authorise every individual on-disk file change operation. It can not be disabled and manually updated as a transaction. This isn't "fixed", it's "ignored".

[tr1s]

Same issue here after installing the 12.6 Monterey update.

[morficus]

Ditto, I started running into this after upgrading to Monterey 12.6

[josefkim]

same goes for me

[dweigl]

I also have this issue and if it helps at all, I also have it with VSCode, Zotero, and Evernote. Although GitHub seems to pop up most frequently (multiple times when opened and then occasionally through the day). I've also had this issue for a while now, including before installing Monterey (previously on Big Sur)

[jayj89]

While I appreciate that in single-user environments the problem appears to be less of a problem, the problem still exists, especially for managed workstations. The update mechanism is not transactional and attempts to authorise every individual on-disk file change operation. It can not be disabled and manually updated as a transaction. This isn't "fixed", it's "ignored".

This, we are still seeing this issue. Specifically on the latest version 3.2.3. End users can't change the user/owner permissions on /Applications/GitHub\ Desktop.app as they don't have the local admin credentials. There needs to be an actual fix for this for enterprise environments using tools like Jamf to deploy applications remotely. How can we get this issue re-opened?