macOS: keychain prompts on every launch when GitHub-signed and Microsoft-signed copilot binaries share login-keychain items (XARA partition mismatch)

Describe the bug

On macOS, copilot stores credentials in legacy login-keychain items (copilot-cli, copilot-mcp-oauth). macOS XARA protection scopes each item's ACL to a partition list containing the Team ID of whoever last wrote it.

The same CLI ships under two different Developer ID Team IDs:

Path	Identifier	Team ID
~/Library/Caches/github-copilot-sdk/cli/<ver>/copilot	copilot	VEKTX9H2N7 (GitHub, Inc.)
/Applications/Microsoft Scout.app/Contents/Resources/app.asar.unpacked/node_modules/@github/copilot-darwin-arm64/copilot.app	com.microsoft.clawpilot.copilot	UBF8T346G9 (Microsoft)

Both read and write the same items, so each one invalidates the other's approval. "Always Allow" never sticks and the user is prompted forever.

From log show --predicate 'process == "securityd"':

09:08:23  ACL partition mismatch: client teamid:VEKTX9H2N7  ACL ("teamid:UBF8T346G9")
09:08:23  asking user about XARA partition for 'teamid:VEKTX9H2N7'
09:08:23  displaying keychain prompt for .../github-copilot-sdk/cli/1.0.73/copilot
09:08:30  user approved 'always allow' -> adding XARA partition 'teamid:VEKTX9H2N7'
09:08:41  ACL partition mismatch: client teamid:UBF8T346G9  ACL ("teamid:VEKTX9H2N7")
09:08:41  displaying keychain prompt for /Applications/Microsoft Scout.app/.../copilot.app
09:47:18  ACL partition mismatch: client teamid:UBF8T346G9  ACL ("teamid:VEKTX9H2N7")
10:03:28  ACL partition mismatch: client teamid:VEKTX9H2N7  ACL ("teamid:UBF8T346G9")

Signature confirmation:

$ codesign -dv --verbose=2 ~/Library/Caches/github-copilot-sdk/cli/1.0.73/copilot
Identifier=copilot
Authority=Developer ID Application: GitHub (VEKTX9H2N7)
TeamIdentifier=VEKTX9H2N7

$ codesign -dv --verbose=2 "/Applications/Microsoft Scout.app/Contents/Resources/app.asar.unpacked/node_modules/@github/copilot-darwin-arm64/copilot.app"
Identifier=com.microsoft.clawpilot.copilot
Authority=Developer ID Application: Microsoft Corporation (UBF8T346G9)
TeamIdentifier=UBF8T346G9

Amplified by an orphaned-item leak. My login keychain held 765 copilot-mcp-oauth items against 8 files in ~/.copilot/mcp-oauth-config/, so 757 were orphans. Creation timestamps show a new batch on every launch:

Month	Items created
Feb-Apr 2026	10
May 2026	138
Jun 2026	364
Jul 2026 (27 days)	253

Three launches on 2026-07-27 produced 10 new items (6 at 15:47:43Z, 3 at 16:08:35Z, 1 at 17:03:34Z), none of which matched a config file -- orphaned on creation. Each orphan is born with a single-Team-ID partition list, so each is a latent prompt.

This overlaps #2112, which diagnoses the stale-entry half on Windows/keytar. The macOS partition-list collision looks separate and unfiled.

Affected version

GitHub Copilot CLI 1.0.75 (Scout-embedded) and 1.0.73 (SDK cache).

Steps to reproduce the behavior

1. On macOS, use a host that embeds the GitHub-signed CLI (e.g. the Copilot app, via github-copilot-sdk).
2. Also use a host that embeds a Microsoft-signed copy (Microsoft Scout).
3. Sign in and configure at least one OAuth-based MCP server.
4. Launch each app in turn. Approve "Always Allow" when prompted.
5. Prompts return on the next launch of the other app, indefinitely.

Expected behavior

Approving "Always Allow" once should be durable. Concretely:

1. When creating keychain items, set a partition list trusting every Team ID the CLI ships under (teamid:VEKTX9H2N7,teamid:UBF8T346G9) rather than letting macOS default to the writing binary's own Team ID.
2. Reuse the existing copilot-mcp-oauth item for a given server instead of writing a freshly-hashed one per launch, and delete the entry it supersedes.
3. Consider the data-protection keychain (kSecUseDataProtectionKeychain plus a shared access group) instead of the legacy file keychain, which sidesteps XARA partition lists entirely.

Additional context

• OS: macOS 26.5.2 (25F84)
• CPU: arm64 (Apple silicon)
• Shell: zsh

Manual workaround -- trust both Team IDs. This is one-time and resets whenever an item is recreated:

security set-generic-password-partition-list \
  -S teamid:VEKTX9H2N7,teamid:UBF8T346G9,apple-tool:,apple: \
  -s copilot-cli ~/Library/Keychains/login.keychain-db

security set-generic-password-partition-list \
  -S teamid:VEKTX9H2N7,teamid:UBF8T346G9,apple-tool:,apple: \
  -s copilot-mcp-oauth ~/Library/Keychains/login.keychain-db

Orphans can be identified by diffing keychain account names against ~/.copilot/mcp-oauth-config/*.json basenames:

security dump-keychain ~/Library/Keychains/login.keychain-db | awk '
  /^keychain:/ { acct="" }
  /"acct"<blob>=/ { l=$0; sub(/^.*"acct"<blob>="/,"",l); sub(/".*$/,"",l); acct=l }
  /"svce"<blob>="copilot-mcp-oauth"/ { print acct }' | sort -u

Deleting the 757 orphans is safe and requires no keychain authorization (deletion does not decrypt the item, so it produces no prompt).

Commencez par localiser les chemins de création des éléments du trousseau et de configuration OAuth associés à copilot-cli, copilot-mcp-oauth et ~/.copilot/mcp-oauth-config/*.json. Reproduisez les lancements alternés avec les deux binaires signés et inspectez les éléments résultants à l’aide des commandes security fournies. C’est terminé lorsque l’approbation persiste pour les deux Team IDs, que l’élément existant du serveur est réutilisé et qu’aucune nouvelle entrée orpheline n’est créée.