[Bug]: After switching Claude account (re-login), T3 keeps showing the old account and its limits for several minutes #29676

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Run T3 with the Claude provider ready / authenticated on account A, which has hit its usage limits.
2. In a terminal, log out of Claude Code and log in with account B (claude, then /login). The login succeeds: ~/.claude/.credentials.json is rewritten and account B has quota.
3. Go back to T3 without restarting it.

Expected behavior

After a re-login (credentials file changed), T3 re-checks the Claude account and its usage limits within seconds, with no restart, so limited threads can continue on account B.

Actual behavior

T3 still shows account A and A's exhausted limits. After quitting and reopening T3, ~/.t3/caches/claudeAgent.json shows account B with a checkedAt later than the credentials write.

I restarted T3 about 3 minutes after the login, so I did not measure how long it would have stayed stale without a restart.

Why it lags (from reading the shipped server bundle):

• The Claude driver's makeManagedServerProvider sets no refreshOnInterval, so a ready snapshot is re-checked by the interval loop: every providerHealthRefreshInterval (5 min in "balanced"), and only when host.shouldRunBackgroundWork({ type: "provider-status" }) is true.
• That re-check goes through capabilitiesProbeCache, keyed by makeClaudeCapabilitiesCacheKey = binaryPath + Claude home + cwd. The key does not depend on the account, and its TTL is CAPABILITIES_PROBE_TTL = 5 min. The interval path (refreshOnInterval -> applySnapshotBase(..., { forceRefresh: true })) does not call invalidateUsageCache; only refreshUsage does.
• So the old account can stay on screen for up to about 10 min (interval + probe TTL), or longer when no client asks for provider status.
• I found no file watcher on the Claude config dir.

Suggested fix:

• Watch the Claude config dir (CLAUDE_CONFIG_DIR or ~/.claude) for changes to .credentials.json (and oauthAccount in .claude.json), debounce about 1 s, then invalidate capabilitiesProbeCache and refresh every claudeAgent instance using that dir.
• Cheaper alternative: add a credentials fingerprint (mtime + size, or oauthAccount.accountUuid) to the capabilities cache key, so a new login misses the cache on the next check.

Possibly related: #14340, #28872, #28928.

Impact

Major degradation or frequent failure

Version or commit

0.1.7-nightly.20261101.4016 (desktop, Nightly)

Environment

Windows 11, T3 Code desktop app (Nightly), Claude provider claudeAgent (subscription login), background activity profile "balanced" (default).

Logs or stack traces

Code inspection notes for the shipped server bundle, version 0.1.7-nightly.20261101.4016 (not a runtime stack trace):

- CAPABILITIES_PROBE_TTL: 5 minutes.
- makeClaudeCapabilitiesCacheKey uses binaryPath, resolved Claude home and cwd; it does not include account identity or a credentials fingerprint.
- DEFAULT_PROVIDER_HEALTH_REFRESH_INTERVAL: 5 minutes in the balanced profile.
- The periodic refresh path calls applySnapshotBase(settings, { forceRefresh: true }) without invalidating the capabilities/usage cache; refreshUsage does invalidate it.

Observed: after successful re-login on the same PC, the current local credentials and T3's cached auth.email referred to different accounts. A direct usage check with the new credentials returned available quota, while T3 still displayed the previous account's limits. After restart, T3 detected the new account.

Limit of evidence: T3 was restarted about 3 minutes after login. No complete runtime log or screenshot of the stale state is attached. A delay of roughly two refresh/cache intervals is inferred from code inspection, not a measured duration.

Screenshots, recordings, or supporting files

No response

Workaround

Quit and reopen T3 Code after switching accounts.