[Bug] Windows: browser cookie extraction fails (Unable to get key for cookie decryption)

[dengshu2]

Environment

• OS: Windows 11
• twitter-cli: v0.8.4 (installed via uv tool install)
• Python: 3.13.6
• browser_cookie3: 0.20.1
• Chrome: latest version (running)

Bug Description

On Windows, twitter feed fails with:

��� Getting Twitter cookies...
DEBUG twitter_cli.auth: chrome in-process extraction failed: Unable to get key for cookie decryption
DEBUG twitter_cli.auth: edge in-process extraction failed: Unable to get key for cookie decryption
WARNING twitter_cli.auth: Twitter cookie extraction failed in both in-process and subprocess modes
❌ No Twitter cookies found.

Root Cause Analysis

I traced through the source code and browser_cookie3 internals. There are two cascading issues on Windows:

1. Cookie DB locked when Chrome is running

browser_cookie3 tries three methods to open the Cookie SQLite database:

Method	Result
sqlite3_connect_readonly	❌ Chrome process locks the file
get_connection_legacy (copy file)	❌ PermissionError — Chrome holds the file
get_connection_shadowcopy (VSS)	❌ RequiresAdminError — needs admin privileges

The actual error when Chrome is running:

shadowcopy.exceptions.RequiresAdminError: This operation requires admin. Please run as admin.

2. Cookie decryption fails even after closing Chrome

After closing Chrome, the DB opens successfully, but AES-GCM MAC verification fails in browser_cookie3's _decrypt method (line 612-615 of __init__.py), raising Unable to get key for cookie decryption.

I verified that DPAPI key decryption itself works fine — CryptUnprotectData successfully decrypts the key from Chrome's Local State file. The failure is in the subsequent cookie value decryption stage, likely a compatibility issue between browser_cookie3 0.20.1 and newer Chrome cookie encryption formats (domain integrity check / SHA256 prefix introduced in Chrome ≥ v127).

3. Misleading error message on Windows

The _diagnose_keychain_issues function in auth.py (line 56-72) only has special handling for darwin (macOS) and falls through to a generic Linux-style message about "keyring daemon" on Windows:

Likely cause:
  System keyring access failed — the cookie encryption key could not be retrieved.
    If running headless or via SSH, ensure your keyring daemon is unlocked.

This is misleading on Windows — it should mention DPAPI / admin privileges / shadowcopy instead.

Suggested Improvements

1. Add Windows-specific diagnostic message in _diagnose_keychain_issues
2. Document that admin privileges may be required on Windows when Chrome is running (for VSS shadowcopy)
3. Consider upgrading or patching browser_cookie3 for newer Chrome compatibility

Workaround

Setting TWITTER_AUTH_TOKEN and TWITTER_CT0 environment variables manually works fine.

[jackwener]

Thanks for the detailed root cause analysis! Fixed in commit 74386ce:

Changes:

1. Added Windows-specific diagnostic message in _diagnose_keychain_issues() — now mentions DPAPI, Chrome DB lock, admin/shadowcopy, and the env var workaround instead of the misleading "keyring daemon" message.

Regarding the underlying browser_cookie3 issue:
The AES-GCM decryption failure with Chrome ≥ v127 is a known compatibility issue in browser_cookie3. This is beyond what we can fix in twitter-cli itself. In the meantime, the recommended workaround is:

export TWITTER_AUTH_TOKEN=<your_auth_token>
export TWITTER_CT0=<your_ct0_token>

I'll keep an eye on browser_cookie3 updates for Chrome v127+ support.