Preserve macOS Keychain access choices

[MelvinCERBA]

Description

On macOS, Keychain trusts the executable that creates a credential by default. Because pgcli runs through Python, saving a password pre-authorizes Python to read it without confirmation. Rewriting an existing credential also resets access choices such as Allow Once.

This is a problem because, for example, you typically don't want your coding agent to be able to access DBs you store the credentials for in Keychain without your manual approval.

This PR preserves the user's Keychain access choices:

• New credentials are created without any pre-authorized application, allowing the user to choose Allow Once or Always Allow on the next access.
• Existing credentials are updated in place so their access controls remain unchanged.
• Passwords loaded from the keyring are not rewritten after successful authentication.
• A replacement entered after a rejected stored password is still saved.
• Non-macOS platforms and custom keyring backends keep their existing behavior.

Implementation-wise, pgcli preserves keyring's normal backend selection, including chained backends. For native macOS Keychain, it reuses keyring.backends.macOS.api: existing items are updated with only kSecValueData, preserving their access controls, while new items receive a SecAccess created from an empty trusted-application list. The few Security.framework calls not exposed by keyring are bound through ctypes.

The implementation supports keyring 23.1 through 25.x. Regression tests cover native backend detection, chained and custom backends, ACL-preserving updates, and creation with no trusted applications.

Checklist

• I've added this contribution to the changelog.rst.
• I've added my name to the AUTHORS file (or it's already there).

• I installed pre-commit hooks (pip install pre-commit && pre-commit install).
• I verified that my changes work as expected (this may include manually testing them in your local environment, or in other available environments). Cross this out if not relevant (for example, if you're making a documentation change).
• Please squash merge this pull request (uncheck if you'd like us to merge as multiple commits)

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-14T09:40:11.032640Z	bc44b6f	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[UsmanGhias]

Hi Melvin, thanks for putting this together! This is a fantastic security improvement that prevents python from unnecessarily pre-authorizing keychain credentials on macOS, protecting users from unintended background access.

Technically, I really like how cleanly you separated the macOS specific logic into macos_keychain.py while keeping the fallback path intact for other platforms. One minor thing to double check is the ctypes memory management and error handling across different macOS versions, but the unit tests look quite thorough and cover the core code paths well.

Overall, this is very neat work. Happy to see this land once CI passes.

Best,
Usman