[kosesena]

Browser login stores the session JWT and token together, which can exceed the Windows Credential Manager's 2560-byte limit and trigger the CredWrite failure reported in #276.

This keeps short entries compatible and stores larger secrets as bounded ASCII chunks in the OS keyring. It publishes a versioned manifest after all chunks are written, retains the old value on a failed write, removes replaced/deleted chunks, and supports rollback and corrupt-entry reads. No plaintext file fallback or additional dependency is introduced.

Validation: regression test fails on the original implementation under a simulated Windows byte limit; 60 targeted tests pass with 100% statement and branch coverage of keyring_store. Full offline suite: 3732 passed, with the same two terminal-rendering failures reproduced on unmodified main (3723 passed there). Actual Windows validation and the complete repository gate remain pending. The local gate passed lint, formatting, type, architecture and complexity checks, then stopped because markdownlint is unavailable.

Draft for maintainer review of the storage approach; not claiming Windows CI or all required gates are green.

[aikido-pr-checks]

Exposed secret in tests/test_keyring_large.py - low severity
Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

_{Reply @AikidoSec ignore: [REASON] to ignore this issue.
More Info}

[kosesena]

This is a synthetic test fixture, not a credential. The value is constructed locally as "assemblyai-chunks-v1:" + "a" * 32 + ":1"; it is not issued by any service and grants no access. The test intentionally uses a string matching the versioned chunk-manifest format to verify that a secret with that shape can still be stored and read back unchanged. Changing it to a non-matching placeholder would remove that regression coverage.

[kosesena]

Hi @alexkroman, a gentle ping on this one when you have a moment. It's meant to fix the Windows CredWrite failure reported in #276, where the browser-login session exceeds the 2,560-byte Credential Manager limit.

One note on the red checks: the CI, CodeQL and PR overlap runs for this PR finished without any jobs starting, so they never actually tested the code. I suspect it's the workflow policy for PRs from forks, but I haven't confirmed that. If the workflows need maintainer approval, I'd be glad to fix anything they surface.

I'd especially value your view on the storage approach: chunked keyring entries plus a versioned manifest, with no plaintext fallback. If you'd prefer a different design, I'm happy to rework it. Thanks!