feat(server): provider credentials can live in 1Password - #27
Conversation
yordis
commented
Aug 20, 2026
yordis
commented
- Running several accounts of one provider means several long-lived tokens, and each one had to be copied out of the password manager into a second store before it was usable. That second copy is the one nobody rotates: it outlives the original, has no expiry anyone tracks, and sits in a file that gets synced and backed up.
- Pointing at the secret instead of duplicating it keeps a single copy under the policy that was chosen for it, and turns rotation into a vault edit plus a refresh rather than a hunt for everywhere the value was pasted.
- Holding the resolved value in memory is what makes it usable rather than merely correct. Reading the vault on every thread start turns an occasional biometric prompt into a constant interruption, and that friction ends with the token pasted back in plaintext to make it stop.
- A reference that cannot be read leaves the variable unset rather than blank, so the provider reports as not authenticated instead of starting with an empty credential and failing on the first message.
Running several accounts of one provider means several long-lived tokens, and each had to be copied out of the password manager into a second store to be usable. That copy is the one nobody rotates. Pointing at the secret keeps a single copy under the policy chosen for it, and makes rotation a vault edit rather than a hunt for everywhere the value was pasted. Signed-off-by: Yordis Prieto <[email protected]>
Signed-off-by: Yordis Prieto <[email protected]>
PR SummaryHigh Risk Overview Resolved values are cached in process until Settings refresh. Refresh invalidates the cache and rebuilds only instances that use secret references (including currently unavailable ones), so a rotated vault item reaches a new provider process without restarting every agent. Failed reads unset the variable rather than substituting empty or inheriting the server’s env, so the provider shows unauthenticated. The instance registry gains Reviewed by Cursor Bugbot for commit b5d7b9b. Bugbot is set up for automated code reviews on this repo. Configure here. |
github-actions
Bot
added
vouch:trusted
|
Warning Review limit reached
Next review available in: 21 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (26)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Resolving a secret can park on a person at a biometric prompt, and for that whole window a rebuild was observable: lookups handed back a torn-down instance, a settings change landing mid-rebuild was silently reverted, and an instance a locked vault had failed to rebuild stayed gone until settings changed. Signed-off-by: Yordis Prieto <[email protected]>
An instance being rebuilt is briefly neither live nor unavailable, and the aggregator treats an id it finds in neither list as gone, so a provider could vanish from Settings for as long as the secret store took to answer. A refresh with no explicit target also only reached live instances, which left the one instance that most needed retrying, the one a locked vault had just failed to rebuild, waiting on a settings edit instead. Signed-off-by: Yordis Prieto <[email protected]>
…n credential A provider process starts from the server's environment, so leaving an unreadable reference out of the resolved variables was not the same as leaving it unset: a machine that already exported the same name handed the agent that credential instead, under the account the instance did not name, and reported it as authenticated. This is the behavior the secrets guide already describes. Signed-off-by: Yordis Prieto <[email protected]>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 1f94869. Configure here.
… rebuilding The request that asks for a refresh can go away while 1Password is still waiting on a fingerprint. The registry only recorded what it needed to retry after the build returned, so an interrupt in that window left the instance with no live entry and no envelope, and the refresh button, its only recovery path, had nothing to act on. Signed-off-by: Yordis Prieto <[email protected]>
1 participant
