[Bug] OAuth token refresh holds the auth.json lock across the network call

[Adolanium]

Affected area

Coding agent and CLI

What happened?

refreshOAuthTokenWithLock holds the auth.json lock for the whole HTTP refresh. A slow or hanging provider blocks every other process from reading or writing credentials for up to 30s. The sync retry path gives up after about 200ms and throws.

Steps to reproduce

1. Store an expired OAuth credential.
2. Start a refresh (any command that needs a live API key).
3. While that HTTP call is in flight, have another process read or write auth.json.
4. The second process blocks until the 30s stale threshold, or the sync retry throws after about 200ms.

Expected behavior

Hold the lock only to read and later to write. Refresh over the network with no lock held. If another process stored newer credentials in the meantime, keep those and drop our result, because refresh tokens rotate on use.

Prime Agent version

0.7.1 / source as of 2026-08-08

Environment

Reproduced from source.

Additional context

Original report: #999

Tested patch, closed in the August 15 backlog sweep: #1001

[awhite0030]

Investigated this report and produced a candidate fix, validated on a fork of this repository.

Root cause, fix and validation from the working notes:

Root cause: refreshOAuthTokenWithLock holds the auth.json lock across the entire HTTP network request, causing other processes trying to read or write credentials to block for up to 30s or throw.
Fix: Refactored refreshOAuthTokenWithLock to split the lock into two phases: one to read/validate the current credential and copy details, and a second to write the network response. The actual network request (getOAuthApiKey) is performed while the lock is released. If another process refreshes the token in the meantime, their changes are kept and ours are discarded.
Validation: Wrote a regression test using a mock async locking backend to simulate concurrent updates during a network request. The test verifies that the network request executes without holding the lock and concurrent updates correctly override the local refresh response. Ran npx tsx ../../node_modules/vitest/dist/cli.js --run test/suite/regressions/1768-oauth-refresh-lock.test.ts (Passed). Ran npm run check globally (Passed).
Upstream discussion: #1768

Diff: awhite0030/prime-agent@main...fix-oauth-refresh-lock-14037132116416936199
Full pull request: awhite0030#18

The change passes npm run check and the focused regression tests against current main. If a fix for this is still wanted, I can open a pull request.

[Adolanium]

@awhite0030 Same situation as on #1769 and #1770. I diagnosed this in #999 and shipped the patch in #1001 on Aug 8. This discussion restates both. Your fork PR implements that same fix.

A few things that aren't independent rediscovery:

• Same split: hold the lock to read, refresh with no lock held, hold it again to write.
• Same conflict rule: if another process stored newer credentials while we were on the network, keep theirs and drop ours, because refresh tokens rotate on use.
• Test file is the same case with the discussion number swapped in: 999-oauth-refresh-lock.test.ts vs 1768-oauth-refresh-lock.test.ts. Both assert the lock is free during the refresh and that a concurrent write wins.

Calling this an investigation that produced a candidate fix leaves out that the writeup and the patch were already mine. If this goes anywhere, credit #999 / #1001 and @Adolanium.

I already asked you on #1769 and #1770 not to refile other people's reports as your diagnosis. Please stop.