Previously, when the /cli/cliAuthEnabled API was unreachable (network
error, timeout, 5xx, etc.), both OAuth and Device Flow login modes
silently assumed CLI access was enabled (fail-open). This allowed users
to "successfully" log in even when their organization had not granted
CLI data access, leading to confusing failures on subsequent API calls.
Changes:
- Reverse the check logic in OAuth callback: treat any error as
"not enabled" instead of "enabled", showing the permission request
page so users can take action.
- Block login in Device Flow when the check fails, with a clear
error message asking users to verify network connectivity.
- Add retry with backoff (3 attempts, 0s/1s/2s) to
CheckCLIAuthEnabled to tolerate transient network issues.
- Add retry with backoff (3 attempts) to FetchClientIDFromMCP
(/cli/clientId) for the same transient-error resilience.
- Add i18n entries (en/zh) for new error messages.
- Add 19 tests covering server error, connection refused, malformed
JSON, timeout, transient-then-recovery, business error, and full
Device Flow loginOnce integration scenarios for both endpoints.
Made-with: Cursor
When logging in with --client-id and --client-secret, credentials are now
automatically persisted to enable automatic token refresh after expiration.
Client secret is securely stored in system Keychain, config file only
contains a reference.
fantiu