TortoiseGit credential storage lacks automatic expiration handling

TortoiseGit stores Git credentials in the Windows Credential Manager and reuses them for subsequent operations without checking their validity. The goal is to prevent repeated authentication failures caused by expired or revoked tokens while preserving offline usability.

However, it is unclear whether TortoiseGit should automatically validate credential expiration before each Git operation, how to handle cases where the credential helper cannot reach the identity provider, and what impact such validation would have on performance and user workflow.

Should TortoiseGit pre‑flight validate stored tokens against the server’s expiration policy? Could it automatically invoke a refresh flow on receiving a 401 response instead of persisting the stale credential? Is there a feasible way to integrate with existing credential‑helper mechanisms to enforce least‑privilege scopes without requiring manual credential‑manager edits?