feat: Add shm credential store for headless auth#849
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 344a2526db
ℹ️ 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".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
d47478f to
1121523
Compare
1121523 to
daa9201
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: daa92018c0
ℹ️ 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".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review |
Headless Linux users can complete OAuth device auth now, but the CLI still tries to persist tokens in a desktop keyring. On machines without a working keyring, or where gnome-keyring loses the login item, users fall back to
BUILDKITE_API_TOKEN.This adds an explicit
--credential-store shmmode forbk auth loginthat stores access and refresh tokens in a 0600 JSON file under a per-user/dev/shm/buildkite-cli-<uid>/directory. The defaultautomode still prefers the OS keyring, but can fall back to the shm store and read it later so users do not need to pass a flag on every command.Example:
The shm store is ephemeral and clears on reboot, which matches the issue request for a headless/session-like credential store without writing tokens to shell env or persistent config.
Fixes #807