[alukach]

Stacked on #22 (per-environment caches). Retarget to main once #22 merges.

Problem

macOS keychain entries trust only the binary that created them. Release binaries aren't signed with a Developer ID, so after every CLI upgrade the Keychain asks for the user's password once for each entry: the login session plus one per role, per environment. A user with a couple of roles across prod and staging gets a burst of password prompts after each upgrade.

Change

• Role credentials (STS keys) go in the 0600 cache files, not the keyring. They're short-lived and re-created from the session, much like the AWS CLI's own ~/.aws/cli/cache. A creds call that finds fresh credentials never touches the keyring.
• The login session, which holds the long-lived refresh token, stays in the keyring (with the existing file fallback on headless machines).
• No logout on upgrade: role reads try the file first, then the keyring, so credentials cached by earlier versions are still found. The next login writes a file that takes precedence.
• Entries from v0.3.0 or earlier that carry their own refresh token keep being written to the keyring, so a refresh token never lands in a plain file.
• README: the storage section now describes the split.

Result: after an upgrade, one keychain prompt per environment (for the session), and only when credentials actually need re-creating.

Testing

• cargo test and cargo test --features staging: 30 passed, including the new role_entries_round_trip_through_their_file
• cargo clippy --all-targets: clean
• Manual: creds with HOME pointed at a temp dir holding only a file-cached entry prints it, with no keychain access
• Not exercised against a real keychain, to avoid password prompts: the fallback read of entries written by earlier versions. It's the same keyring read as before, now running only when the file is missing.

🤖 Generated with Claude Code

[claude]

Claude finished @alukach's task in 15s —— View job

---

✅ No blocking issues — safe to merge.

I read the diff and traced the read, write, delete and login paths. I did not run the tests or build.

• New login entries have refresh: None (src/main.rs:937, src/main.rs:1034). They go to the file, and forget_keyring_credentials only removes old entries. It can't delete a refresh-bearing keyring entry just written, so the ordering in run_login is safe.
• delete_slot removes both the keyring entry and the file, so logout leaves no copy behind.
• write_role removes the stale file after a refresh-bearing entry is written to the keyring. That stops read_role replaying a spent refresh token.

Non-blocking notes:

• forget_keyring_credentials (src/cache.rs:339) calls delete_credential() on every login, even when no keyring entry exists. On macOS that can still trigger a Keychain access prompt, which this PR is meant to reduce. This only happens on login, so it is rare.
• When creds renews a role that was read from the keyring, the old keyring entry stays until the next login. If the file is deleted later, the stale entry is read again. The README already says this, so the behavior is documented.

Simplify (ponytail)

• src/cache.rs, write_slot / read_slot: if only the session uses these, they could be renamed to write_session / read_session. The "generic slot" wording no longer fits, and the T: Serialize/DeserializeOwned generics could be dropped if the session is the only user.
• src/cache.rs, keyring_location(): a one-use helper. It could be inlined, or write_keyring could return the location.

---

💰 Estimated review cost: $0.13 · 0m15s · 5 turns