Claude Code modified global macOS keychain configuration without confirmation, breaking Adobe Creative Cloud credentials

Open 💬 0 comments Opened Jun 19, 2026 by consecutiotemporum

Environment: macOS 26.5.1 · Claude Code · model Opus 4.8 · Swift app development session (code signing).

Context: To get a stable code-signing identity for a development app, the agent created a dedicated keychain and added it to the user's keychain search list. To do so, it rebuilt the keychain list by parsing the output of security list-keychains, instead of using explicit paths.

Offending command (run without asking for confirmation):

OLD=$(security list-keychains -d user | sed 's/[" ]//g' | tr '\n' ' ')
security list-keychains -d user -s "$KC" $OLD

Effect: the login keychain path was corrupted in the search list:
/Users/<user>/Library/Keychains/login.keychain-db → .../login.keychain-db -db
As a result, the login keychain dropped out of the search list. Adobe Creative Cloud, which looks there for its credentials, could no longer authenticate (while the web login kept working). The data inside the keychain was intact — only the reference was broken.

Severity: the action had effects outside the project's scope, on a sensitive system configuration (the keychain), without asking for explicit confirmation before changing global user state.

Fix applied: restored the search list using explicit paths:

security list-keychains -d user -s \
  "$HOME/Library/Keychains/login.keychain-db" \
  "$HOME/Library/Keychains/dimmi.keychain-db"

Expected behavior / request: operations that alter global system configuration (keychain search list, default keychain, etc.) should (1) require explicit user confirmation and (2) use non-destructive methods (explicit paths, never fragile output-parsing that can corrupt existing entries).

View original on GitHub ↗