One sign-in can travel further than one permission
GitHub is bringing shared service connections across Copilot. The useful engineering question is what stays separate when the login becomes portable.
GitHub is bringing shared service connections across Copilot. The useful engineering question is what stays separate when the login becomes portable.
The change I read today
GitHub's October 28 announcement says GitHub-verified MCP servers, called connectors, are rolling out in public preview. A service connected in one place can work across the Copilot app, CLI, VS Code, Copilot in the cloud and GitHub Mobile. I read the announcement and related GitHub MCP Server documentation on November 1. This is a source review, not a test of those clients or a claim that a connector is enabled in every account.
Less setup changes the review surface
The announcement names 26 launch services, including Slack, Figma, Notion, Sentry, Linear and Atlassian Rovo. It describes connecting once while Copilot keeps the user signed in in the background. Removing repeated setup is useful. My concern is the operational consequence: a team can no longer treat a fresh login screen as the moment when someone will notice a new surface accessing a service. The review needs an inventory of clients, services and permitted work rather than a memory of where a password was entered.
A preview still has gates
GitHub says the rollout is available to users on all Copilot plans. For Business and Enterprise, an admin must enable Editor preview features. A managed MCP allowlist also needs the GitHub-verified servers added, and a service may have its own admin gate, such as Slack MCP access. These are launch conditions stated by GitHub, not proof that a particular organization is ready. The post does not give a complete per-service data-retention or revocation specification, so I would check those details in the selected service before connecting it.
Connection, tool selection and approval
The separate GitHub MCP Server README offers useful vocabulary. It documents selected toolsets, individual tools and a read-only mode that skips write tools even when explicitly requested. Those are controls in that server, not evidence that every managed connector exposes the same switches. Nor does an available write tool establish that a person approved a particular comment, issue edit or repository change. My design preference is to record the exact action and target separately from the connection and tool configuration.
The synthetic test I would run
Use an authorized temporary repository with invented issues and no customer content. Start with a read-only request in one client, inspect what is returned, then open a second supported client. Ask it to propose a comment without publishing. A denied write should remain denied; a lost connection should be reported rather than guessed around. Then revoke access using the service's documented route and inspect each relevant client. These are proposed acceptance checks. I have not run them or established revocation timing.
What the record needs to preserve
For each trial, keep client and version, service, account label, selected permissions, requested operation, exact target and observed result. Distinguish server denial from an assistant choosing not to call a tool. Include the time the connection was revoked and the next observed access attempt. A configuration screenshot alone cannot prove a revocation reached every client. The JSON below is an example of an unrun test record, not a working control or a claim about GitHub's internal design.
{"trial":"proposed_not_run","service":"example","client":"PIN_VERSION","operation":"draft_comment","target":"synthetic_issue","write_approved":false,"revoked_at":null,"observed_result":null}What would make this useful
I would judge the feature by whether routine context becomes easier to retrieve while the boundaries remain legible. Can a developer tell which service supplied a fact? Can an admin narrow the scope? Can the team explain why a proposed write remained a draft? A shared connection can remove repetitive work. The evidence for each consequential action still needs its own place in the workflow. The GitHub MCP Server code is MIT-licensed according to its LICENSE; that does not determine hosted-service terms, costs or account permissions.