Skip to content

Core functionality breaking following an app upgrade #121

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ethanndickson opened this issue Mar 25, 2025 · 5 comments
Open

Core functionality breaking following an app upgrade #121

ethanndickson opened this issue Mar 25, 2025 · 5 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@ethanndickson
Copy link
Member

ethanndickson commented Mar 25, 2025

Many users, including myself, have noticed the core functionality of the app breaks when the app is upgraded, be it via homebrew, or via the .pkg installer.

This issue is identified in two ways:

  1. The app being unable to load the user's workspaces, i.e. if this message is displayed when the logged in user certainly owns workspaces. Restarting Coder Connect does not fix it, and typically neither does merely restarting the app.

Image

  1. Coder Connect cannot be started, with an error citing the app is not open (and that it must be open during first-time setup).

Image

Both of these issues have the same root cause - the System Network Extension process is unable to communicate with the Coder Desktop application over macOS' XPC.

In the first case, no XPC connection exists to communicate the list of connected workspaces.
In the second case, no XPC connection exists to instruct the app to prompt the user for sudo, in order to mark the .dylib downloaded from the Coder server as safe to execute.

Multiple users on the Apple developer forums have reported this issue in recency:
https://developer.apple.com/forums/thread/711713
https://developer.apple.com/forums/thread/667597
https://developer.apple.com/forums/thread/742992
https://developer.apple.com/forums/thread/728063

Attempts to fix, based off thread responses:

Apple Feedback Assistant

https://feedbackassistant.apple.com/feedback/17032197

(Private link, I believe)

Apple Developer Forum

https://developer.apple.com/forums/thread/779395

Workaround

However, if a user encounters this issue on upgrade, the fix is relatively straightforward. Unfortunately, due to macOS security decisions, it's not possible for the app to automate these steps in totality.

macOS <=14

  1. Delete the application from /Applications
  2. Restart your device

macOS 15+

  1. Open System Settings
  2. Select General
  3. Select Login Items & Extensions
  4. Scroll down, and click the (i) for Network Extensions
  5. Select the (...) next to Coder Desktop, select Delete Extension, and follow the prompts.

This issue is a successor to #83.

@ethanndickson
Copy link
Member Author

As of 25/03/2025, I think the best next step is to contact Apple developer technical support, checking if there's any progress on this issue in their internal bug tracker, as a post on the forum would imply it's been recorded there.

@EdwardAngert

This comment has been minimized.

@matifali
Copy link
Member

This is now consistently reportable for me after each upgrade. No workspaces appear following each upgrade. I upgrade using the .pkg installer and do not use Homebrew.

@ethanndickson ethanndickson self-assigned this Apr 7, 2025
@ethanndickson
Copy link
Member Author

ethanndickson commented Apr 7, 2025

The dev forum thread I made has gotten some attention from Apple DTS: https://developer.apple.com/forums/thread/779395

Going to be working on this intermittently.

@ethanndickson
Copy link
Member Author

ethanndickson commented Apr 14, 2025

As mentioned in that dev forum thread, our attempted fix in #92 hasn't been working consistently. #134 effectively ports that fix to older installations that still use the "CoderVPN" configuration.

ethanndickson added a commit that referenced this issue Apr 15, 2025
One thing I noticed as part of my work on #121 is that our attempted fix introduced in #92 wasn't working as expected if the user had a VPN configuration installed before #86. 

This PR fetches the unique name of the VPN service dynamically, as part of the script, such that the service is started and stopped regardless of whether the service is called "Coder" or the older "CoderVPN".

This also ensures we don't break it again if we ever change that name, such as to "Coder Connect" (I don't totally recall why it was set to "Coder", but I don't mind it)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

3 participants