Summary

Fixes #62099. On Windows, concurrent config hot-reload can leave auth-profiles.json with a ReadOnly attribute. The atomic write in saveAuthProfileStore then throws EPERM, and because markAuthProfileGood / markAuthProfileUsed / markAuthProfileFailure run as post-completion bookkeeping, that throw used to cascade into the LLM request that had already succeeded. Fallback triggers, hits the same read-only file, fails the same way. The gateway becomes unresponsive; restarts don't help because the file attribute persists.

The fix wraps the body of each mark* function in try/catch, logging the persistence failure and continuing. Caller-visible behavior is unchanged on the happy path.

What this does NOT change

saveAuthProfileStore itself still throws on failure. OAuth token refresh (in oauth.ts) depends on that behavior, since a silent token-save failure would be a security concern. Only the three mark* functions that run after a successful provider call now tolerate save errors.

Scope

• src/agents/auth-profiles/profiles.ts - wrap markAuthProfileGood body in try/catch, log warn
• src/agents/auth-profiles/usage.ts - wrap markAuthProfileUsed and markAuthProfileFailure bodies in try/catch, log warn
• src/agents/auth-profiles/usage.persist-nonfatal.test.ts - new regression tests, one per mark function, simulating EPERM from both the lock-guarded and direct save paths

markAuthProfileCooldown delegates to markAuthProfileFailure so it's covered transitively.

Before

Error: EPERM: operation not permitted, copyfile
  'auth-profiles.json.<uuid>.tmp' -> 'auth-profiles.json'
    at Object.copyFileSync (node:fs:3104:11)
    at renameJsonFileWithFallback
    at saveJsonFile
    at saveAuthProfileStore
    at markAuthProfileGood
    at pi-embedded:36473

The LLM response arrived, then the save threw, then every fallback hit the same file, then the gateway ran out of models. User hits attrib -R on the file and restarts to recover.

After

The save throws, the catch runs, the warning lands in the subsystem log, the mark function returns void, the LLM request completes normally. lastGood / usage stats stay slightly stale until the next successful save, which is the right tradeoff for a bookkeeping write.

Testing

• New tests in usage.persist-nonfatal.test.ts pass (3/3). Mocks both updateAuthProfileStoreWithLock and saveAuthProfileStore to throw EPERM, asserts the mark* functions resolve without throwing.
• Existing usage.test.ts (39 tests) and auth-profiles.markauthprofilefailure.test.ts (9 tests) still pass. Also verified auth-profiles.runtime-snapshot-save.test.ts (1 test).
• Two pre-existing test failures in state-observation.test.ts and oauth.fallback-to-main-agent.test.ts already fail on main, unrelated to this change.
• oxlint --type-aware clean on modified files.
• tsgo --noEmit clean (exit 0).
• oxfmt --check clean.

Risk

Low. Behavioral change is scoped to the error path of a bookkeeping function. Callers that previously got an unhandled rejection on EPERM now get a resolved promise, which is the intended outcome. Profile state in memory stays authoritative; disk just gets slightly stale until the next successful write.

AI disclosure

This change was drafted with Claude Code acting as coding assistant. The issue was picked from the triaged backlog, the root-cause analysis and implementation plan were produced interactively, and tests were written against the exact stack trace in the issue report. Human review of the patch and regression tests before submission.

Understanding confirmation

Yes, I've read CONTRIBUTING.md and VISION.md. This is a single-concern bug fix with no dependency updates, no schema changes, and no new public APIs. The affected module is src/agents/auth-profiles/. No Carbon changes, no @ts-nocheck, no lint suppression.