Windows: cookie-store access can fail while Chrome is running, even after GitHub cookies are readable as v10

[drogers0]

Windows: cookie-store access can fail while Chrome is running, even after GitHub cookies are readable as v10

Summary

On Windows, gh-image can still fail to read Chromium-family cookie stores while Chrome is running, even after the GitHub session cookies have been reissued in the older v10 format and are no longer blocked by App-Bound Encryption.

This is a separate issue from Chrome 127+ v20 ABE decryption.

The decryption problem can be resolved by disabling ABE and refreshing GitHub cookies. After that, gh-image succeeds when Chrome is closed, but can still fail when Chrome is open due to Windows cookie-store access behavior.

Environment

• OS: Windows
• Browser: Chrome with an active GitHub session
• Command:

gh image C:\path\to\image.png --repo owner/repo

Expected Behavior

Once the relevant GitHub cookies are readable as v10, gh-image should work whether Chrome is open or closed.

Actual Behavior

With Chrome running, the command can still fail while reading browser cookie stores:

Error: reading browser cookies: ...
The process cannot access the file because it is being used by another process.

With Chrome closed, the exact same command succeeds.

Reproduction

Precondition:

• ABE has already been disabled
• GitHub cookies have already been refreshed and reissued as v10

Verified cookie state:

github.com / __Host-user_session_same_site : enc_len=111 prefix=v10
.github.com / dotcom_user : enc_len=71 prefix=v10
.github.com / logged_in : enc_len=66 prefix=v10
github.com / saved_user_sessions : enc_len=123 prefix=v10
github.com / user_session : enc_len=111 prefix=v10

Repro A: Chrome running

1. Leave Chrome running.
2. Run:

gh image C:\path\to\image.png --repo owner/repo

Observed result:

• gh-image fails with Windows file access errors while reading cookie stores.

Repro B: Chrome closed

1. Close Chrome completely.
2. Run the same command.

Observed result:

![image.png](https://github.com/user-attachments/assets/<uuid>)

This proves the upload path is valid once cookie acquisition works.

Diagnostic Findings

After the relevant GitHub cookies were reissued as v10, the failure changed:

• it was no longer a decryption failure
• it became a live cookie-store access failure while Chrome was open

Representative error shape:

Error: reading browser cookies: cookie store: open ...
The process cannot access the file because it is being used by another process.

This strongly suggests a Windows-specific browser-store access problem, likely related to one or more of:

• SQLite cookie DB access while Chrome holds the DB live
• profile scanning across multiple Chromium-family browsers and paths
• how kooky opens and iterates browser stores on Windows

Related Local Prototype Findings

A local prototype added:

• a better Windows ABE-specific error message
• GH_IMAGE_COOKIE support as a manual bypass

Those changes help with the separate v20 issue, but they do not fix this live-access problem while Chrome is running.

Workarounds and Mitigations

Workaround 1: Close Chrome completely

This is the simplest reliable workaround once the relevant GitHub cookies are already v10.

Pros:

• No manual cookie extraction needed
• Keeps the normal browser-cookie flow intact

Cons:

• Inconvenient
• Does not match the macOS experience where the tool was observed to work with the browser open or closed

Workaround 2: locally prototyped GH_IMAGE_COOKIE escape hatch

A local prototype added a manual cookie escape hatch:

set GH_IMAGE_COOKIE=<paste-user_session-cookie-value>
gh image C:\path\to\image.png --repo owner/repo

Pros:

• Bypasses browser-store access entirely

Cons:

• Manual
• Session rotation still applies

This is not assumed to exist in the unmerged upstream state. It is included here because it worked as a practical mitigation during debugging.

Alternative Package / Tool Options

1. Temp-copy the cookie DB before opening it

This is the most realistic next fix.

If the database access pattern on Windows is the problem, then a fallback that copies the Chromium cookie DB to a temp file and reads the copy may allow gh-image to work while Chrome is still running.

Pros:

• Keeps the current architecture
• Least invasive likely code fix
• Does not require external tooling

Cons:

• Needs Windows-specific implementation and testing
• May not help if some stores are locked before copy/open succeeds

2. Narrow browser/profile scanning

Instead of scanning every Chromium-family browser and profile, prefer the most likely current Chrome profile first.

Pros:

• Could reduce unrelated file-open errors from missing or locked stores

Cons:

• Less comprehensive than the current generic scan

3. CookieKatz / ChromeKatz family

Process-memory fallback on Windows:

• avoids the on-disk cookie DB entirely
• may work even while Chrome is running

Pros:

• Bypasses both DB access and v20 decryption issues

Cons:

• High trust / maintenance cost
• Likely AV / EDR friction
• Much more invasive than DB reads

4. DevTools Protocol fallback

If Chrome is launched with remote debugging enabled, cookies may be retrievable via the browser itself instead of through the DB.

Pros:

• Cleaner than process memory reading

Cons:

• Not available by default

Proposed Fixes

Short-term

1. Document that closing Chrome is currently the most reliable Windows workaround after cookies are readable
2. Consider adding a manual cookie escape hatch such as GH_IMAGE_COOKIE

Medium-term

1. Add a Windows-specific temp-copy fallback for Chromium SQLite cookie stores
2. Retry from the copied DB
3. Reduce noise from unrelated browser/profile probes where practical

Long-term

1. Evaluate a DevTools Protocol fallback when available
2. Evaluate whether a Windows-only process-memory fallback is acceptable

Acceptance Criteria

• On Windows, if the relevant GitHub cookies are already v10, gh image ... should succeed whether Chrome is open or closed.
• If that is not yet possible, the docs should clearly state that Chrome must be closed.

Notes

• This issue is separate from the Windows ABE v20 decryption issue.
• The upload flow is working correctly. The remaining failure is in browser cookie acquisition while Chrome is running.