[Bug] macOS Keychain repeated and frequent prompts to allow access
- 主要言語
- 言語のデータがありません
- スター
- 2.1k
- フォーク
- 153
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
macOS Keychain prompts constantly for `copilot-mcp-oauth` — a new keychain item is created on every token refresh, and "Always Allow" never persists.
**Affected version:** v1.0.25
## Summary
On macOS, the GitHub app repeatedly triggers a system Keychain password prompt for the keychain service `copilot-mcp-oauth`. Clicking **Always Allow** does not stop it — I'm asked for my macOS login password many times a day to unlock Keychain for the GitHub App.
## Environment
- GitHub app version: 1.0.25 (latest installed)
- OS: macOS 26.5.2 Tahoe
- Keychain service affected: `copilot-mcp-oauth`
- Related MCP integration: Power BI (token scope `https://analysis.windows.net/powerbi/api/user_impersonation`)
## What I observed
- The `copilot-mcp-oauth` keychain contains a large number of separate entries — **63 for today alone**.
- Each entry stores a short-lived OAuth token, e.g.:
`{"accessToken":"","expiresAt":1784716427,"scope":"/powerbi/api/user_impersonation"}`
- A new entry appears to be created on **every token refresh** rather than updating a single existing entry.
## Actual behavior
A new keychain item is created on each refresh. Because macOS "Always Allow" trust is granted **per item**, it never applies to the newly created items — producing constant password prompts and dozens of stale entries per day.
## Possible cause (two mechanisms likely compounding)
1. **Per-refresh item creation** — the token cache writes a new keychain item instead of overwriting one, so previously granted access never applies.
2. **Unstable ACL / code-signing identity** — if the accessing helper process isn't stably code-signed, macOS treats each access as a new requester and re-prompts even for an existing item. This is the classic reason "Always Allow" fails to persist.
## Impact
Password fatigue plus dozens of stale OAuth entries accumulating in the login keychain every day. Disruptive to normal workflow.
## Steps to reproduce
1. Use the GitHub app on macOS with the Power BI MCP integration authenticated.
2. Continue normal use so the OAuth access token refreshes (tokens are short-lived).
3. Observe a macOS Keychain access prompt for `copilot-mcp-oauth`.
4. Click **Always Allow**.
5. On the next token refresh, the prompt reappears.
6. Open **Keychain Access** and search `copilot-mcp-oauth` — note the growing count of distinct entries.
## Expected behavior
Tokens for a given MCP integration are stored in (and updated within) a **single** keychain item, so granting **Always Allow** once persists and no further prompts appear.
コントリビューションガイド
調査の方向性
`copilot-mcp-oauth` の macOS Keychain アクセスパスを、トークンキャッシュの更新/書き込みロジックと MCP OAuth 統合から開始して追跡します。更新によって個別のアイテムが作成されるかを確認し、helper の署名 ID と ACL の動作を調査します。統合ごとに 1 つのアイテムがその場で更新され、「Always Allow」が繰り返しプロンプトを表示せずに保持されることを完了条件とし、関連するテストが存在する場合は回帰テストのカバレッジも追加します。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- macos
- 領域
- authentication, desktop, security
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 静か
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 45/100