Questions for using this in our enterprise use case

[bblechman-ebay]

My company is evaluating Github copilot, and I've been tasked with enabling this for our Xcode users. I've gotten security clearance to use your great CopilotForXcode extension. Thanks for providing this! I have a couple questions

1. Only Github Copilot has been approved for use at my company at this time, and only for a limited number of users during a pilot. If we decide to move forward with this, there will be security concerns about the other integrations your extension provides. I am considering forking your repo to publish an internal version that only supports Github Copilot, and not Open AI, Azure, etc. I understand that a user would actually have to authenticate with these other services to enable them, but that may be too tempting to put out to many developers, with a high probability of someone doing the "wrong thing" from a security standpoint (at our company). Is this something you have considered, and might there be a cleaner way to do this where a custom build could disable certain features via env vars at build time or similar?

2. VSCode considers all open tabs for context when getting code suggestions from copilot. Does Copilot for Xcode also do this? Or is only the currently open tab?

[intitni]

1. Sounds reasonable but I don't have time for that now. Here's a solution that sounds easier to accomplish:

   1. Remove all the setting pages that you don't need in the HostApp target.
   2. Open Keys.swift file in the Preferences target, create a new type conforming to UserDefaultPreferenceKey, use the type on every key that you don't want your users to change.
   3. In UserDefaults.swift, update the getter to check the type, and always return the default value.

2. The app also considers all open tabs for context when getting code suggestions.

[bblechman-ebay]

Thank you for the quick response!

[martinm82]

@bblechman-ebay do you have already a fork with the GitHub Copilot feature only?