jroth1111

Totally understand if this isn't a direction you want in core — consider this a proposal with a concrete implementation you can cherry-pick from (or close entirely). Why I think...

Thanks — re: credential storage, I agree **Bun.secrets / system keyring** is probably the right long-term direction (and I see #4318 is already tracking that). My current branch uses **encrypted...

Re the possible-duplicate bot note: totally fair — this overlaps with a few threads. - #5391 covers *multi-account/auth profiles per provider* (this proposal implements that as provider+namespace+label records + pool...

@rekram1-node totally agree re: using Bun.secrets / system keyring for how secrets are stored (and +1 to aligning with #4318). The main value I’m aiming for here is *multi-account OAuth...

I created a new focused PR that aligns with the Bun.secrets/keychain direction and scopes to the core value (multi-account OAuth subscription failover): - #5754 auth: multi-account OAuth subscription failover Highlights:...

@rekram1-node quick update — I took your feedback and narrowed this down to the core value, while avoiding overlap with the keyring work in #4318. - Focused PR: #5754 (multi-account...

Heads up: I tightened this PR further to maximize mergeability and keep it focused on the core value (multi-account OAuth subscription failover w/ same-request rotation). Key points: - Only **OAuth...

This supersedes #5754 with a simpler, more maintainable approach: - **File-based storage** instead of OS keychain — avoids complexity and potential conflicts with #4318's broader keyring work - **Per-provider configurable...