Couple enterprise environment papercuts

Beginne damit, die drei gemeldeten Verhaltensweisen mit Copilot for Xcode 0.31.0 unter Xcode 16.2 und macOS 15.2 zu reproduzieren, installiert mit HOMEBREW_CASK_OPTS=--appdir=~/Applications. Prüfe, ob eine benutzerbezogene Installation das interne CA-Vertrauen, die Accessibility-Berechtigungen und das leere Xcode Source Editor-Berechtigungsfenster beeinflusst; abgeschlossen ist die Aufgabe, wenn jedes Verhalten eine bestätigte Ursache und entweder eine definierte Behebung oder eine dokumentierte Einschränkung hat.

Describe the bug
Had a couple issues that I am trying to work around in documentation, but would be better handled in app

1. Lack of keychain support for internal CA breaking TLS
   • We have a transparent egress, but TLS will require custom CA support. So while I can work around this via Advanced and hard-coding a proxy and disabling strict SSL ideally if the connection used Keychain and/or the SDK HTTP requests than the CA trust should be covered by our existing keychain management.
2. Accessibility Permission missing
   • Installed using brew to ~/Applications and the Accessibility item was not created
   • Was able to add it manually, but couple extra steps needed as it defaults to /Applications.
   • Guess is this is context specific and if I installed using admin consent to /App the Accessibility item would have been added
3. Blank entry in Extension Permission
   • Xcode Source Editor was added to Extensions, but when using the info icon the panel was empty. Basically to blank sections where the XSE graphic and the enable/disable for "GitHub Copilot for Xcode" should have been. Sorry didn't grab a screenshot of that one.
   • Restarted Xcode, but didn't reboot the mac or logout/login
   • Next day the element was fully populated (machine lock, but no reboot or new session), but not sure what fixed it.

Versions

• Copilot for Xcode: 0.31.0
• Xcode: 16.2
• macOS: 15.2

Steps to reproduce

1. Install via brew using HOMEBREW_CASK_OPTS=--appdir=~/Applications
2. Launch and try to configure as normal

Additional context
My bet is it's my use of ~/App vs /App to avoid elevated permissions impacting the two Permissions, but be great to get a confirmation on if that is the case. If User scoped is an expected install context (guessing not) and if it can be an option. If it shouldn't be than checking for Admin etc should probably be baked in. Can't see any reason ~/App shouldn't work just yet, but may be missing it.