Claude repeatedly assured keychain code was correct despite fundamental flaw

What happened

During development of a macOS app (Quicker IP), Claude was asked to implement keychain storage for license keys. Claude wrote the keychain code without kSecUseDataProtectionKeychain, which means every time the app binary changes (i.e. every update), macOS shows a password prompt dialog to the user — multiple times per launch.

The user asked Claude three separate times across the development process whether the keychain migration was solid. Each time Claude confirmed it was fine without considering what happens when the app's code signature changes between builds.

This resulted in:

• A shipped build (v2.1.0) that prompted users for their macOS password 5+ times on launch
• The password dialog wording ("Quicker IP wants to use your confidential information") looked like the app was harvesting credentials
• The update had to be pulled from both Sparkle (auto-update) and LemonSqueezy (distribution)
• A GitHub release had to be deleted
• The developer lost hours re-archiving, re-signing, re-notarizing

The core problem

Claude was asked multiple times to verify the keychain implementation. Rather than deeply researching macOS keychain ACL behaviour (per-app code signing vs Data Protection keychain), Claude gave surface-level "looks good" assurances. This is basic macOS keychain knowledge — the default keychain uses per-app ACLs tied to code signatures, and kSecUseDataProtectionKeychain: true is the standard way to avoid password prompts across app updates.

Expected behaviour

When a user asks Claude to verify critical code multiple times, Claude should actually research and think deeply rather than rubber-stamping its own earlier work. "I already looked at it" is not verification.

---
Filed by the developer via Claude Code.