You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Had a couple issues that I am trying to work around in documentation, but would be better handled in app
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.
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
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
Install via brew using HOMEBREW_CASK_OPTS=--appdir=~/Applications
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.
The text was updated successfully, but these errors were encountered:
Figured out a couple more things. And just as a baseline the out of box for us is
[2025-03-07T16:51:46.501Z] [info] [GitHubCopilot] [92223] window/logMessage: {
"type" : 1,
"message" : "[default] Error sending telemetry FetchError: self-signed certificate in certificate chain\n at fetch (\/snapshot\/copilot-client\/node_modules\/@adobe\/helix-fetch\/src\/fetch\/index.js:99:11)\n at processTicksAndRejections (node:internal\/process\/task_queues:95:5)\n at cachingFetch (\/snapshot\/copilot-client\/node_modules\/@adobe\/helix-fetch\/src\/fetch\/index.js:288:16)\n at B1e.fetch (\/snapshot\/copilot-client\/lib\/src\/network\/helix.ts:94:22) {\n type: 'system',\n _name: 'FetchError',\n code: 'SELF_SIGNED_CERT_IN_CHAIN',\n errno: undefined,\n erroredSysCall: undefined\n}"
}
I did realize it doesn't seem like changes to the proxy settings are active until after a restart of the app. That definitely gave me some false results, but made an educated guess given the alert from the Verbose switch. If that is true than probably should add an alert when the settings are adjusted.
With that in mind i can disable SSL even without specifying a proxy and get a clean connection to GitHub which is a fine workaround for the moment. I would prefer to avoid NODE_EXTRA_CA_CERTS like directives and hopefully helix-fetch has some options to load CAs or better use system-ca resources.
Describe the bug
Had a couple issues that I am trying to work around in documentation, but would be better handled in app
brew
to ~/Applications and the Accessibility item was not createdVersions
Steps to reproduce
HOMEBREW_CASK_OPTS=--appdir=~/Applications
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.
The text was updated successfully, but these errors were encountered: