Add option to remove GitHub Pull Request as Default

[cjdbarlow]

Issue

Positron currently ships with the GitHub Pull Requests and Issues extension installed by default. We use an in-house Git server because our repositories contain data that has legal restrictions on how, and particularly WHERE, it can be held.

For that reason, we deliberately do not want GitHub in our development environment. We can disable or uninstall the GitHub Pull Requests extension, but subsequent Positron updates automatically enable/install it again. This has caused an issue where a new repository without an origin defined defaulted to GitHub sync and prompted a sign in from a user with a GitHub account.

Proposed fix

Positron should provide a way to permanently opt out of the bundled GitHub integration, through either:

• Respecting the removal of default extensions across updates
• Providing a setting option to opt-out of installation of bundled extensions

[MLuc24]

There is a detail here that probably explains why disabling the extension did not prevent the incident you describe: there are two separate GitHub components in Positron, and the sign-in prompt almost certainly came from the other one.

The one you disabled is bundled from upstream, declared in product.json under builtInExtensions:

{
    "name": "GitHub.vscode-pull-request-github",
    "version": "0.162.0",
    "repo": "https://github.com/Microsoft/vscode-pull-request-github",

Those are fetched at build time and shipped inside the application directory, which is also why deleting it does not stick — an update replaces that directory wholesale.

But "a new repository without an origin defaulted to GitHub sync" is the publish flow, and that lives in a first-party extension held in the Positron tree itself, extensions/github, which contributes:

{ "command": "github.publish", "title": "%command.publish%" }

That one is not a bundled third-party extension at all — it is part of the product, like the Git extension. So a policy that only removes GitHub.vscode-pull-request-github would leave the behaviour that actually bit you completely intact. Worth folding into the request, because the two need different treatment.

On the immediate need, the closest existing lever is extensions.allowed, which Positron carries over from upstream:

export const AllowedExtensionsConfigKey = 'extensions.allowed';

The useful part for your situation is that it is not merely a user setting — build/lib/policies/policyData.jsonc declares both extensions.allowed and extensions.allowed.policy, so it can be pushed as machine-level policy that users cannot undo and updates do not reset. That is much closer to what an organisation with legal constraints on data location actually wants than asking each user to disable something.

I would test whether it reaches built-in extensions before relying on it, though. isAllowed in allowedExtensionsService.ts has no built-in exemption in the function itself, but whether built-ins are routed through that check at all is decided by the call sites, and I have not traced those. If it turns out built-ins are exempt, that is a sharper and more actionable version of your feature request than "provide an opt-out" — namely, make extensions.allowed authoritative for bundled extensions too, since the policy plumbing already exists and only the coverage is missing.

[juliasilge]

Thanks for this question, @cjdbarlow! We do provide a way to do this. Check out the docs at: https://positron.posit.co/extensions.html#bootstrapped-extensions

You'll want to use extensions.allowed and do something like this:

{
    "extensions.allowed": {
        "GitHub.vscode-pull-request-github": false,
        "*": true
    }
}

[cjdbarlow]

Oh outstanding! Thank you.