OAuth tokens too long for Windows keyring

Thanks for reporting. The keyring feature isn't supported on Windows currently. I'm going to change this from a bug report to a feature request. In the meantime, I'll make it clearer in our documentation, and we'll work on getting a better error message in place.

Oh, I take that back. I just heard back from the Codex team member who implemented the keyring support, and she confirmed that this should work on Windows. So it sounds like this is a bug. She'll investigate.

Hi @celia-oai @etraut-openai, I'm a developer interested in contributing! I saw this report about OAuth tokens exceeding the 2560-character limit in Windows Credential Manager. Since I'm on Windows, I'd like to work on a fix involving token chunking for the keyring store. Does that approach sound good to you?

Hey! I've been looking into the TooLong errors on Windows and wanted to share the root cause and a potential path forward.

Root Cause

On Windows, the Credential Manager (which the keyring crate uses) has a hard limit on the length of the secret (the "password" field). This limit is roughly 2560 bytes (which equates to 1280 UTF-16 characters).

As OAuth tokens grow (especially with larger JWT payloads or session data), they are hitting this system-level constraint, leading to the TooLong error during login.

Proposed Fix: Token Chunking

The most reliable way to handle this without changing the storage backend is to implement transparent chunking in the keyring-store.

When a value exceeds a safe threshold (e.g., 2048 bytes):

1. Split the value into multiple chunks.
2. Store a "manifest" in the primary key with a header (e.g., CODEX_CHUNKED:N:<checksum>) where N is the number of chunks.
3. Store the actual data chunks in auxiliary keys (e.g., account:1, account:2, ...).

Implementation Logic

1. Write Path: Detect length. If too long, calculate chunks. Store chunks first, then store the manifest key.
2. Read Path: Check for the CODEX_CHUNKED header. If present, load all auxiliary keys, verify integrity (e.g., via checksum or just length), and reassemble.
3. Delete Path: Ensure that auxiliary keys are cleaned up when the primary key is deleted.

Verification

I've tested this logic locally with tokens up to 10,000 characters. It successfully bypasses the Windows Credential Manager limits while maintaining compatibility with the existing keyring API used by Codex.

---

I had a draft implementation ready, but since the guidelines are now invitation-only, I'm sharing the analysis here first. Happy to help more if the team wants to pursue this approach!

Following up on the discussion in PR #10732, I'm moving the technical analysis for the proposed fix for this issue here as requested by @etraut-openai.

Technical Analysis for #10353

What?
Implement transparent token chunking for the Windows keyring to bypass the hard 2560-byte limit of the Windows Credential Manager.

Why?
Modern OAuth tokens often exceed the Windows limit. Without chunking, authentication fails silently for Windows users, creating a major platform disparity.

How?

• Chunking Mechanism: Splits tokens into 1024-char chunks stored as multi-part credentials (e.g., token, token:1).
• Transparent Reconstruction: Uses a CODEX_CHUNKED: header to automatically reconstruct the full token during load operations.
• Comprehensive Logic: Handles load, save, and delete operations to ensure orphaned chunks are correctly cleaned up.

I have verified this implementation with tokens up to 5000 chars on Windows 11. If this fits the team's intended approach for solving this, I'd value an invitation to move this forward.

this is closed by the PR stack ending in #27541.

Thank you!