Keychain authorization prompt on every launch of a dev build — make grants stick or avoid the cross-app read (chatbox reference)

[kiki830621]

Problem

Original text:
「https://github.com/chatboxai/chatbox 這裡面好像有不用每次開都要授權一次鑰匙圈的方法，我也想要用」
— Source: user report, 2026-07-27

Every launch of a locally-built Logos pops the macOS keychain authorization dialog (「Logos」想使用你在鑰匙圈中的「Claude Code-credentials-…」). Clicking 永遠允許 does not stick across rebuilds. The user wants what chatbox delivers: open the app, no keychain prompt, ever.

Type

feature

Priority

P2

Expected

Launching Logos (including day-to-day dev builds) never interrupts with a keychain authorization dialog. A one-time grant, if any, persists.

Actual

The dialog reappears on (nearly) every launch of a rebuilt app, blocking the terminal/claude spawn until dismissed.

Initial evidence (to confirm at diagnose)

Two compounding causes on the Logos side, plus what chatbox actually does:

• Cross-application keychain read: Sources/LogosUsage/ClaudeKeychain.swift reads the claude CLI's own credential items (Claude Code-credentials / Claude Code-credentials-<hash>, read-only SecItemCopyMatching — used e.g. for needs-login/usage surfacing). Those items were created by a different binary, so macOS requires user authorization, and an 永遠允許 grant is recorded against Logos's code signature.
• Ad-hoc signature churn: make bundle / make install sign with codesign --sign - — every rebuild gets a fresh ad-hoc identity, so the previously granted ACL no longer matches → macOS asks again. (make release-signed uses a stable Developer ID, where a grant would stick.)
• What chatbox actually does (local reference clone of chatboxai/chatbox): it never touches the macOS keychain at all — settings and API keys live in localStorage / electron-store plain files (its safeStorage.ts is a localStorage wrapper, not Electron's safeStorage). Zero keychain use → zero prompts, at the cost of plaintext credential storage.

Fix directions to evaluate (diagnose decides)

1. Stable dev signing: sign dev bundles with the Apple Development identity instead of ad-hoc (the Track-B signing identity already exists per project docs), so one 永遠允許 grant persists across rebuilds. Lowest-effort, keeps the security posture.
2. Drop or defer the cross-app keychain read: detect needs-login/usage state without SecItemCopyMatching on claude's items (e.g. probe via the claude CLI itself, config-dir artifacts, or lazily on explicit user action rather than at launch), so routine launches perform no keychain access at all — chatbox's UX without chatbox's plaintext trade-off.
3. Not recommended as-is: copying chatbox's storage model (plaintext files) — conflicts with Logos's documented security posture (secrets live in the keychain; README "Local data & privacy").

Impact

• Every dev-build launch is interrupted; the dialog also blocks the hosted claude spawn until dismissed.
• Automated launches (smoke tests, dogfooding) inherit the same modal interruption.

Clarification (added post-filing)

Original text:
「我想用鑰匙圈但是卻不用每次都要重新授權的方法」
— Source: user, 2026-07-27

Scope locked: the solution MUST keep credentials in the macOS keychain (no chatbox-style plaintext storage — fix direction 3 is now formally out of scope). The goal is chatbox's outcome (zero authorization prompts), achieved via directions 1 and/or 2: a stable code-signing identity for dev builds so a one-time grant persists, and/or removing or deferring the launch-time cross-application keychain read so routine launches perform no ACL-prompting access. Storage stays in the keychain either way.

Current Status

Phase: closed

Clarity Surface(idd-clarify run 2026-07-27T07:51:20Z)

Type	Source	Suggested canonical	Status
ambiguity	"我也想要用"	Wanting chatbox's (a) outcome — zero prompts — vs (b) exact method — no keychain, plaintext storage. Body interprets as (a) with Logos's keychain security posture preserved (fix direction 3 rejects (b)); confirm at diagnose.	resolved @ 2026-07-27T07:55:33Z (reason: user confirmed — keep the keychain, eliminate re-authorization; see Clarification below)
missing-context	"the dialog reappears on (nearly) every launch"	Full inventory of which keychain accesses fire at launch is unverified — the observed dialog names claude's credential item, but whether Logos's own service item or other reads also prompt after a signature change needs confirmation at diagnose.	resolved @ 2026-07-27T08:00:51Z (reason: inventory complete — the ONLY keychain access in Logos is LogosUsage's read-only SecItemCopyMatching on claude's items, launch-triggered by the status bar's usage fetch; LogoSwitch has a red-line test making any SecItem call a compile error, and Logos stores no own-service secrets. Details in Diagnosis)

[kiki830621]

Diagnosis

Type

feature

Root Cause / Analysis

Launch-time keychain access inventory (resolves the Clarity Surface row; every claim verified in code):

1. Exactly one keychain access path exists in Logos: LogosUsage — SystemKeychainReader.readGenericPassword (ClaudeKeychain.swift:93, read-only SecItemCopyMatching, never Add/Update/Delete) on the claude CLI's credential items (Claude Code-credentials / -<hash8> service names).
2. It fires at every launch: the always-visible status bar's PlanUsageStatusItem runs .task { … await registryUsage.refreshAll() } on appear → per-account AccountUsageModel.refresh() → keychain read → the authorization dialog. (Re-fires on window-account change and from the usage window; refreshAll coalescing First-run Keychain authorization dialogs stack (concurrent refresh triggers N simultaneous prompts) #51 already guarantees at most one dialog per refresh.)
3. Nothing else touches the keychain: LogoSwitch has a red-line audit test making any SecItem* call a compile error, and per Extract LogoSwitch — a first-party-safe Swift module for claude multi-account switching + auth #34 ("auth is claude's own job") Logos stores no credential copies of its own — the README's historical app.getlogos.logos.credentials service is not an active prompting source.

Why the prompt repeats on every launch: make bundle / make install sign the app ad-hoc (codesign --sign -). An ad-hoc signature's designated requirement is anchored to the CDHash — which changes on every rebuild. A keychain ACL grant (永遠允許) records the requesting app's code requirement; the next build no longer matches it, so macOS asks again. The grant can never stick, by construction.

Why one authorization is inherent (and acceptable): the items belong to another program (claude CLI), so macOS requires the user to authorize Logos once. The user's clarified requirement (keep the keychain, eliminate repeated authorization) is exactly what a stable signing identity delivers: with an Apple Development (or Developer ID) signature, the designated requirement is anchored to the Team ID + identifier + certificate chain — stable across rebuilds — so a single 永遠允許 persists forever. (make release-signed already signs stably; only the dev-build path is ad-hoc.)

Impact

• 影響的檔案：Makefile（bundle target 的 codesign 行）、CHANGELOG/README 註記
• 影響的使用者流程：每次開 dev build 的鑰匙圈打斷消失（換簽名身份後每個 item 最後再授權一次，之後永久有效）

Strategy

• make bundle: resolve a stable signing identity — prefer the machine's Apple Development certificate (already required for Track B per project docs), falling back to ad-hoc (-) with a visible warning when no identity exists (other machines / CI keep today's behavior, never break).
• Guard/verify: after signing, surface which identity was used in the bundle output line so the fallback is never silent.
• Docs: CHANGELOG entry + README note (one final authorization per credential item after the identity switch, then grants stick).
• Verification: rebuild twice and diff codesign -dr - designated requirements (must be identical across rebuilds with the cert; CDHash-anchored/different when ad-hoc) + live launch check.

Not pursued (documented): deferring/removing the usage-fetch keychain read (direction 2) — the read powers the core usage HUD, moving it only relocates the one-time prompt, and with a stable identity the repeated-prompt problem is fully solved at the signing layer.

Conflict Class

A_parallel_safe — Makefile + docs only; no shared external resource.

Complexity

Simple

• Layer 1 not hit (behavior change, code/build). Hard-gate: not triggered — 2-3 files, one concept, no shared abstraction (Hard-gate: not triggered — Makefile codesign line + docs; no cross-file symbol spread).
• Layer P considered and not hit: the change touches build tooling, not credential-handling code (the read-only keychain seam is untouched); identity resolution has a single obvious approach with a fail-open ad-hoc fallback; a wrong outcome fails loudly at build/sign time rather than corrupting state. Precedent: the Installed Logos.app crashes at launch: SwiftPM resource bundles never embedded, Bundle.module dev-path fallback broken by .build clean #99 bundle fix (same file, higher stakes) ran Simple.

Vagueness Pre-check

• V1: 2 — WHAT is locked by the user's clarification: keep keychain, eliminate repeated authorization.
• V4: 2 — acceptance is concrete: rebuild → relaunch → no dialog after one final grant; designated requirement identical across rebuilds.
• Triggered: no — both axes ≤ 3.

Risks

• Machines without an Apple Development certificate silently... — mitigated: the fallback prints a visible warning, behavior identical to today (ad-hoc + prompts).
• Multiple Apple Development certificates in the keychain make bare codesign --sign "Apple Development" ambiguous — resolve to a specific identity hash via security find-identity.
• --deep re-signs the embedded SwiftPM resource bundles — resource-only bundles, no entitlement implications; release-signed path untouched.

Sister Concerns Filed (mid-diagnose)

(none) — the red-line audit already confines keychain access to the single LogosUsage seam; no sibling access paths exist to fix.

Residue

One final authorization per credential item after the identity switch is inherent to keychain ACLs (cross-application item access) and accepted by the user's clarification. Machines without a cert retain today's prompting behavior by design (documented fallback). Flagged, not dropped.

[kiki830621]

Verify

Method: proportional to the change (3-file build-tooling fix, no Swift code touched) — mechanical proof of the causal mechanism + branch coverage + regression run, in the attended verify loop.

Result: PASS

1. Root-cause mechanism fixed (decisive, mechanical): two consecutive make bundle runs with a modified binary produce byte-identical designated requirements anchored to identifier "app.getlogos.logos" + the Apple Development certificate chain — no cdhash anchor. A keychain ACL grant recorded against this requirement matches every future rebuild, which is precisely what ad-hoc signing made impossible.
2. Signature integrity: installed /Applications/Logos.app passes codesign --verify --deep --strict (valid on disk, satisfies its designated requirement; embedded SwiftPM resource bundles re-signed cleanly).
3. Fallback branch: forcing DEV_SIGN_ID= empty reproduces the no-certificate machine — ad-hoc signing with the visible Keychain authorization prompt on every launch of a dev build — make grants stick or avoid the cross-app read (chatbox reference) #101 warning, today's behavior preserved, never silent.
4. Regression: 576 tests / 72 suites, sole red = the documented loadAsync timing flake (unchanged count — no drift; no Swift sources modified).

Honest boundary: the end-to-end "no dialog on the next launch" requires the one-time 永遠允許 grant first (inherent to cross-application keychain ACLs, accepted in the issue's Clarification) — that click is the user's; the mechanical requirement-stability proof above covers the entire causal chain up to it. After granting once, rebuilds can no longer invalidate the grant.

Phase: verified

[kiki830621]

Closing Summary

Problem

Every launch of a locally-built Logos popped the macOS keychain authorization dialog for the status bar's usage lookup, and 永遠允許 never stuck across rebuilds. The user's clarified requirement (recorded verbatim in the body's Clarification section): keep credentials in the keychain, eliminate the repeated authorization — chatbox's outcome without chatbox's plaintext-storage method.

Root Cause

Diagnosed with a full launch-time keychain-access inventory (which also resolved the issue's Clarity Surface rows):

• Logos has exactly one keychain access path: LogosUsage's read-only SecItemCopyMatching on the claude CLI's credential items, fired at every launch by the always-visible status bar's usage fetch (PlanUsageStatusItem → refreshAll; per-refresh coalescing First-run Keychain authorization dialogs stack (concurrent refresh triggers N simultaneous prompts) #51 already capped it at one dialog). LogoSwitch has a red-line audit test making any SecItem* call a compile error; Logos stores no credential copies of its own (Extract LogoSwitch — a first-party-safe Swift module for claude multi-account switching + auth #34).
• The prompt repeated because make bundle signed ad-hoc: an ad-hoc designated requirement anchors to the CDHash, which changes on every rebuild, so the keychain ACL grant recorded at 永遠允許 could never match the next build — non-sticky by construction. (Cross-application item access makes one authorization inherent; only the repetition was fixable, exactly matching the clarified requirement.)

Solution (f9545e7, pushed to origin/main)

make bundle now resolves the machine's Apple Development certificate at make time and signs dev bundles with it — the designated requirement anchors to identifier "app.getlogos.logos" + the certificate chain, identical across rebuilds, so a single 永遠允許 persists forever. Machines without the certificate fall back to ad-hoc with a visible warning (today's behavior, never silent). Credential storage and the read-only access pattern are untouched; make release-signed (Developer ID) unaffected. CHANGELOG + README updated in the same commit.

Verification

• Mechanical proof of the causal mechanism: two consecutive builds with a modified binary produce byte-identical, certificate-anchored designated requirements (no cdhash) — the exact property ad-hoc signing lacked.
• Installed app passes codesign --verify --deep --strict; fallback branch simulated (DEV_SIGN_ID= forced empty → ad-hoc + Keychain authorization prompt on every launch of a dev build — make grants stick or avoid the cross-app read (chatbox reference) #101 warning).
• Regression: 576 tests / 72 suites, sole red = the documented loadAsync timing flake (no Swift sources touched).
• Honest boundary (also in the Verify comment): one final grant per credential item is required after the identity switch — that click is the user's; after it, rebuilds can no longer invalidate the grant.

Residue acknowledgement

The diagnosis-time residue — one inherent final authorization per item, and cert-less machines retaining today's prompting behavior via the documented fallback — is a permanent, accepted boundary (accepted in the issue's Clarification), not deferred work. Nothing to file.

Doc-sync 檢查

2 files checked (README.md, CLAUDE.md) — README synced in the fix commit itself (signing/first-launch paragraph rewritten); CLAUDE.md's Track-B signing notes are unaffected by the dev-bundle change. No staleness.

Changes

• f9545e7 — fix: sign dev bundles with a stable identity so keychain grants persist (Makefile + CHANGELOG + README)
• Reference: chatboxai/chatbox local clone inspected during filing — its "method" turned out to be no keychain at all (localStorage/electron-store), documented in the body as rejected for Logos; the adopted fix delivers the same outcome while keeping the keychain.