Complicated process required to control macOS 10.14 (Mojave) clients

sgtpoliteness 3 years ago updated by David Geddes 2 years ago 75

Setting up Connectwise Control on macOS 10.14 (Mojave) clients is difficult and requires many extra steps as compared with previous macOS versions.

To set up Connectwise  Control on a brand new install of macOS 10.14, these steps are required:

  1. Install .pkg as normal (this allow remote viewing but no control)
  2. Reboot macOS computer
  3. After reboot, attempt remote control, this will prompt a popup asking if the macOS computer wants to allow
  4. Click "Open System Preferences"
  5. Click lock (bottom left), enter computer password
  6. Check box next to "screnconnect-xxxxxxxxx"
  7. Reboot
  8. Remote control again works

In cases where remote control was working on a macOS 10.14 computer where Connectwise upgraded from 6.6 to 6.7, connectwise software must first be removed using these steps:

  1. From Access website, select session > End > Uninstall and end
  2. On macOS computer, open system preferences > accessibility
  3. Click lock (bottom left), enter computer password
  4. select "screenconnect-xxxxxxxxx", click - to remove
  5. Reboot
  6. Install using steps above

I believe this complexity is due in part to some sort of increased system security in the new macOS.  Still, it seems much of this could be streamlined.

ConnectWise Control Version:
Server Affected:
Host Client Affected:
Guest Client Affected:

Thanks for the detailed report. Development is actively working on this issue.

Any updates on this issue please? The above fix didn't work for me, but I was able to get a VNC program to run by adding VNCAgent in the privacy box.  I have a few headless Mac servers I am wanting to upgrade to Mojave, but cannot do that until this is resolved.

Could you elaborate on what didn't work? If manually granting the permissions somehow failed, then it might be a slightly different problem. In that case, I'd encourage you to contact support so we can take a closer look at your case.

I can connect and see the screen, but cannot control using the keyboard or mouse.  I'll contact support.

Hey all. I'm pretty familiar with Mojave's ins and outs. Based on what I'm seeing, the only way to get keyboard and mouse going again is go to follow the original steps above while physically on the computer. The only other way we've seen around this is to use Apple Remote Desktop (ARD) and/or VPN to get into the Mac, since it doesn't require a 3rd-party authentication.

It seems to work OK on machines that haven't had SC on them before, but the ones I have tried with existing SC connections even after ending and reinstalling do not appear to work properly...

I've just tried deleting and adding again from the privacy screen and on the second attempt, it worked... very strange...

Thanks for the update. Is it possible that one of the permission request prompts was declined during the first installation?

same is happening to me  10.14 "Mojave"   will do these steps for the quick / long way fix - thanks for the post

I've got two remote macs both on Mojave 10.14 where I can not use the host keyboard / mouse to control the remotes.  Host is also 10.14 Mojave.  I've uninstalled the remote agent, rebooted, and reinstalled and granted all of the recommended permissions, with no success.   I hope there is a fix soon.  


I believe you can fix this if you have physical keyboard and mouse access to the remote computer.

On the remote computer:

  1. open system preferences
  2. click Security & Privacy icon
  3. click Privacy tab along top
  4. click Accessibility on left
  5. unlock using password
  6. select screenconnect-123abc entry
  7. click minus button to remove
  8. reboot
  9. attempt remote control, this should cause access warning to pop up
  10. approve access warning

At this point remote control should work again.

It seems that this process must be repeated each time the ConnectWise Control agent updates.  Since posting this topic a few weeks ago I have had to repeat this on each 10.14 Mac to regain remote mouse and keyboard control.  In each case remote terminal commands always work.

I think it was step 9 I missed initially. You need to have an incoming screenconnect session to add the privacy setting properly.  This will be a nightmare if you have to do this after every update though as a lot of my Macs are headless.

This worked for me.  You have to do Steps 8 and 9.


As a couple of us have pointed out, this does seem to relate to changed security built into the macOS Mojave update.  In other words, much of this might be the same with any remote control tools aside from Apple's remote desktop or VPN.

Here is Teamviewer's guide on this topic:


Still I think ConnectWise Control could be a bit more straightforward on this.  It would be great to see it check for this new security allowance, be more consistent with asking the system for control (as much as Apple allows this), and most importantly, keep remote control allowance through ConnectWise agent upgrades. 

Version 6.6 doesnt look like its signed. You can check by using the following command in terminal codesign -dr - /opt/screenconnect-**********.app

It gives the following response /opt/screenconnect-**********.app: code object is not signed at all

In a future release if ConnectWise release a signed application you can give accessibility access using Jamf by creating a configuration profile. Then users wont need to go into system preferences and approve it, which they need admin access to do and you'll be able to connect to labs to troubleshoot issues instead of just observing.

I haven't tested the newer versions but didn't see any info about it on the release notes.


Here is a write up from Jamf about the new security setting and how to approve it


and here is a link to the tool to approve the application once it gets signed so the user doesn't have to


Thanks for this!  Just to be clear, we need to use tccprofile to create a mobileconfig to distribute to clients via whatever MDM of our choosing? And we can only do this once ConnectWise signs their app? 

Hi Derek, yes that's what I've been required to do for a number of applications to allow accessibility access.

A great resource for info about this is the Macadmin #TCC slack channel


A requirement is that the application has to be signed. I've only been able to test ConnectWise 6.6, I get the prompt that the application in /opt/screenconnect is not signed. I cant confirm if it works correctly on version 6.7 or 6.8 but I haven't seen any information in the release notes.

I did not read all the comments above and others noted some or most of this, but here it is anyway.

OK, after immediately letting ConnectWise know this was a big problem 9.25.18 (Mojave totally breaking ConnectWise Control on Macs), my two lab "test" Macs I had updated to Mojave (testing to see how another program worked) STOPPED working using screenconnect (I could see screen - view it - but nothing else remotely). I finally today looked again and stumbled on this above, while it did not work I kept at it and finally figured it out (and will share what I found - BTW, this worked on 10.14.1 as well, I have both now working yay!) So here is what you need to know extra:

First off I'm not a "Mac" tech, so I know very little on Macs (and kept looking at "Accessibility" and could not find anything called "Accessibility access") it did not match description at all. I kept getting the “allow”  or “deny” choices in the pop up message so I could not follow it (find it). Finally I found it, it’s a “tab” under Security & Privacy (I know the vast majority of folks are saying “Duh”, assume I know less than many savvy Mac users, lol). Anyway after I found it, and then followed directions, still no go. Did the uninstall and reinstall and nothing. I was about to update ConnectWise support and say “Any luck, still totally dead in the water” etc. when I tried something and it finally worked. I then did it on my 10.14Mac and my updated 10.14.1 Mac. It worked on both. And I updated the 10.14 device and ConnectWise Control STILL worked after the update (yay).

What I did is once I found the entry I SPECIFICALLY selected it, and removed it (hit minus button, close and restart Mac). Then after the restart, I used remote to “trigger” the pop up (request) and this time (knowing where to find it) I allowed the new one (looks exactly the same). And I then rebooted again. Even though it “Looks” the same, there must be some difference as it was already “Allowed” but only screen viewing” worked but after I specifically removed it and re-added it (after a restart). It finally totally worked again (yay). Downside big time is having to do it locally, I do not think I can “Walk” someone through what they need to do to allow it. Thanks fully the dozen or so Macs I only support occasionally have NOT updated yet and 10.13.6 is working fine…

BTW, the number after screenconnect-.... (on mine) is totally different (same one both devices) so I suspect it is unique to an account.


Ran into this today - solution for me was simpler than above, just requiring the screen connect to be added to the security * privacy tab.  

System Preferences > Security & Privacy >Privacy > Accessibility

Search for the Screen Connect app from the search window and click Open

Check it's added to the list of apps

As I had view access - I managed to get this done by a remote user, and as soon as it was done I had full control again.  No need for reboots etc..

      This did the trick for me as well.

      The problem isn't so much if your connecting directly to a user because you can ask the user to allow accessibility access as long as they are an admin on the device. If there is no remote user and you are using unattended access, you have no access to do maintenance in labs and kiosks remotely with only view access.


      Just ran into this issue today. Huge pain in the butt; we have a ton of Mac clients, and onboard new ones all the time. I can see this being a dealbreaker if it doesn't get resolved or automated somehow.

      Agreed, huge pain in the butt if a already enabled device upgrades to Mojave.

      I spent quite a while writing very detailed EXACT steps for an end user. I then tested them... Big time investment and hassle (writing, testing and then having end users try it (both worked, yay).

      Here are steps. I would have loved if someone else wrote them out but here is what I have to walk virtually any end user through it...


      Local Mac adjustments needed to “re-enable” remote support on “Mojave” upgraded Macs (must be done by end user locally). Basically we need to delete old permission and allow new one (this must be done locally by an Admin leveled end user we cannot do this for you!)

      1. 1. Log in to your Mojave (10.14) Mac. Click Apple icon (upper left)
      2. 2. Choose “System Preferences…” then choose “Security & Privacy” (top row, toward the right).
      3. 3. On window that pops up go down about 8 choices and click on “Accessibility” (blue circle, white silhouette )
      4. 4. On lower left click the (locked) gold colored padlock to allow changes (it will ask for your login credentials, normal Mac login password again). Padlock should now appear “unlocked”.
      5. 5. Now on the right what was “grayed over” is now bright and selectable (screenconnect-fb7993d5eecfb706)
      6. 6. Click on screenconnect-fb7993d5eecfb706 (so it’s highlighted and turns blue)
      7. 7. Click on minus button (slightly below) and it will disappear totally.
      8. 8. Restart Mac, then login again.
      9. 9. Once logged in, after a brief delay you will greeted with a pop up “screenconnect would like to control this….”.  Click/choose “Open System Preferences”
      10. 10. This will take you to same screen you were on in step 4 above, but this time the grayed out “screenconnect-fb7993d5eecfb706” shown is now the correct one! (allow it)
      11. 11. On lower left click the (locked) gold colored padlock to make changes (it will ask for your credentials, normal Mac login password again). Padlock should now appear “unlocked”.
      12. 12. Now on the right what was greyed over is now bright and full color (screenconnect-fb7993d5eecfb706)
      13. 13. Now click the little box to the left of “screenconnect-fb7993d5eefb706” to create a check mark in the box.
      14. 14. Click the (unlocked) padlock to “lock” your choice (padlock will animate to locked).
      15. 15. Close the “System Preferences”, you’re DONE. (Thanks!)

      After the recent update to Connectwise Control (client version 6.8.20124.6845 to 6.9.21027.6898) I have again lost the ability to control all Mojave computers in my company. It would be great if Connectwise were able to maintain the authorization for remote control from one version to the next.  Several other utilities require this same authorization in macOS Mojave (preferences > privacy > accessibility > unlock and allow), and it seems they can hold this authorization from one software version to another.

      Either way, this enhanced privacy in the new macOS is making it more cumbersome to handle Apple computers in a business environment.


      It is impossible to use Screenconnect with my Mac users. If this does not get resolved, I will look into another software that can handle these types of changes. Every time I talk to customer support, they say reach out to Apple. NOT OK.

      I feel your pain, this is making it difficult for me to support my Mac users and devices.  But it is important to understand the facts here:

      • macOS Mojave (10.14) employs more stringent security which requires a human using a computer to allow remote control
      • This same phenomenon affects other remote solutions (like TeamViewer), this is due to the nature of remote control in macOS and not a shortcoming in the remote software itself
      • It does seem that ConnectWise should not require this step be done each time ConnectWise updates, but this is just my speculation

      In other words, Apple made the changes that cause this, and no software can overcome this. Also ConnectWise could probably handle updates more smoothly for devices set up with permanent access.

      One could go so far as to say that Apple computers and macOS are not a viable solution for larger businesses. Nothing against Apple, but they just focus more on consumer goods these days.

      @sgtpoliteness do you use an MDM like Jamf? If you do are you able to approve the accessibility access using the PPPC Utility app https://github.com/jamf/PPPC-Utility

      I'm currently on version screen connect 6.8 and haven't been able to test version 6.9.

      That is a great suggestion, I have been wanting to try that out. That looks like the best solution to this issue that I have seen.

      I do not have MDM in place, most of my company's Apple computers are stationary or headless. It bugs me that I need to add another layer of complexity and another monthly cost per device to solve this. I'll probably use Jamf for now but I'm considering (for many reasons other than this) just not using Apple computers for my business.

      Is there a way to push out that policy without JAMF? Like, through a bash script via SC?

      Hi Yochai, I'm not sure. I tried using the PPPC-Utility to approve accessibility access but I'm still not able to with 6.9.

      I get the error /opt/screenconnect-xxxxxxxxxxxx.app: code object is not signed at all

      If they sign the /opt/screenconnect-xxxxxxxxxxxx.app application correctly like other apps then the access to accessibility will be able to be approved. I'll wait to the next version that gets released to do a final test. If it still doesnt work then I think I'll have to start looking for an alternative to manage our Mac fleet.

      connectwise support have confirmed that they will not be fixing the certificate, so there will be no way to remotely approve it for Mojave.

      Ticket #11269959

      Anyone able to push out the correct settings via JAMF or any other MDM?

      Any PPPC profile I create still results in users being presented with the dialog box to approve ScreenConnect in Security and Privacy which is not ideal in the least. I've tried allowing it for accessibility, post, events, and a full range of Apple Events (System Events, System UI Server, Finder, and even System Prefs) but nothing works.

      With a signed app, yes. 

      I've signed our app with our developer cert and checking the code signature reports that it's signed correctly. Apps such as JAMFs PPPC utility and TccProfile (which only work with signed apps) can be successfully run against it which further validates that the code signing is OK but I still get the dialog. Which version are you using (we are on 6.9) and can you elaborate on which settings you applied for your TCC profile. Thanks.

      Tom, give this a go:

      Hey Alex.  How did you get /bin/bash to show up under 'Automate other'?  That seems to be the only thing I'm missing in my profile.  Thanks in advance!

      Nevermind!  I have persevered and figured this out on my own.  Thanks for pointing me in the right direction on this.

      Awesome that did it. I had tried adding bash before but only to System Events. Adding it to Accessibility as well both suppressed the prompts and allowed remote users to connect. Thanks!!


      Glad to hear that. Now we just need to convince ConnectWise that signing their app is a good idea and that it will in fact help people. 


      Tom -- I am lost here.  Can you post what command you did?  I am trying to get into my mac remotely and its blocked.  I have terminal access though.  Thanks!

      You'll need MDM access. The terminal won't help you.

      You won't be able to approve these settings remotely unfortunately - you'll either need to be on site or have access to an MDM server that can distribute the appropriate privacy preferences (which is what I did)

      well shoot.  thanks!

      Agreed. Also to have them find a way to allow you to brand the app without destroying the existing code signature.

      @tom, So maybe that's the issue that CW is having. That's the technical challenge, signing apps per tenant. I wish they would just say that and give us a rough estimate on ship date.

      Yeah exactly that's what I believe. Their vanilla app is now code signed but when you put in additions for your organization it breaks that code signing so you have to resign with your own cert. Very annoying especially if you end up building a lot of specific installers. Personally I think they should find a way to store your custom resources in an accessible location (OS X at least provides for this) and generate custom preference files point to those resources which would not in turn break the code signing. But hey that's just me.....


      I'm sure the number of developers that have figured this out is very high. There is a solution. Throwing in the towel and saying it's impossible is just frustrating. 

      Totally agree.

      So I was able to find a file on the Mac that contained the organization name and using sed was able to change it to a different organization but that didn't change what organization was associated with in the control panel. Even after relaunching the app and rebooting the machine.

      However if I changed the organization from the web interface it of course worked and the only file I saw modified on the client was the one I had originally changed.


      So not sure now where else this or other unique information is stored.

      Well after I did some more digging through the forums I found you can reassign the client's organization from the client itself by modifying the session variable (s=) in the ClientLaunchParameters.txt. The issue is that the client only registers it's associated organization the first time it connects to the host. So by modifying this variable you're forcing the client to reregister itself with the server. However.....this doesn't move the existing client record on the server but rather creates a new client record in the organization you specific so you end up with duplicate records. 

      I suppose on OS X you can build a custom installer and modify the ClientLaunchParameters.txt file and don't call the Launch Daemons/Agents until after modification. That would prob work. Still should be an easier way.

      Well I figured out how to build a "generic" installer that with our customizations that I can sign once with our developer cert and reuse for different organizations. It defiantly works better if you use it in conjunction with an MDM solution that is also capable of running scripts but if anyone is interested in my method let me know.

      I am interested, thank you.

      Are you using a MDM solution that allows for running scripts? Not strictly necessary but it makes things easier.

      Yes, we use SimpleMDM. 


      The first thing you would want to do is to create a script that takes in a variable (the organization's name) and then echos only that to a text file someplace on the local machine. /tmp usually works well.

      Then create a Connectwise pkg for any organization you like. Ideally for a very distinct organization name as you will need the information that surrounds that name in the config file. Once the pkg is create it expand it the the package composer/editor tool of your choice or something such as Pacifist. We are going to take the individual components and repackage them exactly as they were created (Launch Agents, Launch Daemon, and application in the /opt folder) but we're going to modify the stock Post install script. Going forward that is the only thing you need to change. All other files can be left as is.

      In the Post Install script make the following changes - 

      Add the following Variables to the top of the script naming them whatever you like:




      The client info that goes in the previous 2 variables can be found at /opt/screenconnect-ApplicationName.app/Contents/Resources/ClientLaunchParameters.txt 

      You'll take the information found before and after the organization name you used and put it in the appropriate variables.

      Add the following line after the variables:

      echo "$BeginningParameter$Organization$EndingParameter" > /opt/screenconnect-ApplicationName.app/Contents/Resources/ClientLaunchParameters.txt

      At the bottom of the script you will see the following variable declaration:

      newClientLaunchParameters - change it so it reads:


      Build your package. You can then sign it with the developer certificate of your choosing so you have a fully validated package for Mojave and can define TCC Profiles. By simply running the script we created at the beginning you can set whatever organization name you like without changing the package overtime. 

      Hope this helps.

      Less than 5% of the devices I manage are Macs. This new security setting is understandable, but annoying to have to workaround, if Control doesn't have something built-in to manage this change.

      Until Connectwise releases an official fix or documented workaround, if there is a current workable solution, could someone please detail the steps and requirements to implement it? I've researched MDM a little, but the learning curve is quite steep. Also, is there a fee involved? Depending on how complex this is, I may opt for a different tool until this is resolved.

      Just to be clear, the new security settings are Apple required/introduced starting with Mojave. They do affect other tools too. The thing I'm asking for is ConnectWise to sign their app (so their customers don't have to). From there, you can use an MDM setup to set the privacy settings remotely with a profile. Other vendors are signing their applications and providing documentation on how to do this. All developers should be signing their applications these days anyway. So it is possible for ConnectWise to make this process better, but no vendor can circumvent the extra requirements that Apple introduced without MDM management. I recommend ConnectWise signs their app, provides a PPPC profile (may be hard the way they uniquely name the .app in /opt, so maybe just instructions) and encourage folks to get setup for MDM/DEP through Apple for those that don't want the extra steps on every computer to remotely control. Apple does not charge a fee for DEP. You can host your own MDM server, or pay someone to do that as a service. Apple does charge for the Developer to sign the App, but again, ConnectWise should be doing that, not every single customer of theirs. It is complex and the learning curve is steep, but it makes managing Apple devices much easier, so it is worth it. I provided many links in my comments on https://control.product.connectwise.com/communities/1/topics/2046-sign-macos-app for how to create and rollout PPPC profiles with MDM, but it only works if ConnectWise or yourself sign the app first. 

      When I go into System preferences to add ConnectWise access it does not let me. Even if I try find the program manually and add it to Security and Privacy section the box stays blank. I have a client with 10 Macs and all of them have the same problem. I am there in front of the macs in person and can't add access to connect wise , team viewer or ISL all are having the same problem.

      Does anyone have a resolution to this problem or have even seen it before?

      Have a screenshot? Did you unlock system preferences pane before dragging?

      Two questions:

      1. Can this be worked around for a screenconnect-abc123 application to allow it accessbility? I'm assuming not since there is all of this kerfuffle.
      2. Without an apple developer account, is there another way I can self-sign this app and throw it into the PPPC tool?  

      I've been watching this since the beginning on the sidelines when the issues with PPPC first showed up in the wild.  If both of these are negative, I'll give Connectwise one more month to fix this.  Otherwise looks like I'll join the others and go talk to Bomgar or Team Viewer who are already beyond this.


      Adding it to accessibility can be done so long as you have a signed app. The Screenconnect app is code signed as is unless you custom brand it which breaks the code signing. In which case you can resign it with your own developer cert.

      I don't think this needs to be explicitly done with an Apple developer cert but it is one of the easiest methods and relatively cheap ($99/yr for a developer account).

      You MUST deploy OS X TCC profiles before installing screen connect and ONLY on machines that are running 10.4 and have a User Approved MDM status first. You cannot deploy profiles on machines that do not meet these criteria or they will fail to install and won't attempt to reinstall themselves in most circumstances. This is an Apple limitation.


      I just happened to notice this comment while talking with someone on a support ticket. One of our developers (Brandon Alexander) recently posted a couple of updates on the feature request for signing the app that may be useful for you here - we are looking at getting some changes made in the next released version to help:


      Why weren't they signing the app in the first place? I sign all of the application packages that I create!

      Brandon explains the reasoning in a bit more technical detail within the comments on the posting I linked (the feature request), but it boils down to the app being a custom app that's created on the fly by each individual Control instance in order to allow similar customization/branding that you see on the primary Windows client, rather than a pre-built app that's simply distributed from a central location.

      Then we should be given the ability to sign the app ourselves. I cannot distribute this app on any more Macs. Add to this, you still have not fixed the issue that causes the discrete GPU on MacBook Pros to be activated. That problem alone is a good reason to remove Screen Connect. The thread I found that is complaining about that issue is over 2 years old! Clearly, no one is working on that. Apple made macOS Mojave available to developers in June last year. I downloaded it immediately and started doing testing with it. Why didn't you? You could have had this fixed before macOS Mojave was released.

      Using Jamf Pro, we would normally be able to add Screen Connect to a list of apps that are essentially whitelisted. This list would be part of a configuration profile that can be pushed out to all Macs. I just tried that today, but I cannot do it because ConnectWise did not sign the application with an Apple developer certificate. Starting with OS X Lion almost 8 years ago, Apple has required apps and extensions to be signed. ConnectWise still does not sign the app, so now I am left with having to make a choice of uninstalling it from every Mac that I manage, or trying to find another way to approve the app. I am not happy with either choice! Add to this, Screen Connect activates the discrete GPU in MacBook Pros, which drains the battery! This has been a known issue for quite a while but no one has bothered to do anything about that. It's clear that the people developing Screen Connect just don't care about Apple users.


      Hi Howie, I use the same process as you for whitelisting apps in Jamf Pro and I'm also hanging out to be able to give Screen Connect accessibility access. If you take a look at this KB it looks like they are working on the problem and hopefully soon have it sorted https://control.product.connectwise.com/communities/1/topics/2046-sign-macos-app#comment-6947

      Time keeps on ticking, ticking, ticking... Any news on this one?  Looks like 4 months since the last discussion, and 5 since we last heard an update (that it may be related to another signing issue, that was marked "completed" 2 months ago.)

      The app is now properly signed, including when customized, and can be whitelisted via whichever MDM solution your prefer.


      This has been fixed for a while - apologies for the late status update.


      What do you do if you don't have an MDM?

      Is there a sample custom PPPC policy that we can reference for setting up our MDM to whitelist ScreenConnect?

      Commenting disabled