fix: warn on config parse errors during auth login

[devin-ai-integration]

Summary

storage::load_config().unwrap_or_default() in the AuthCommands::Login arm silently swallowed config parse errors, causing users with custom api_url/app_url (e.g. staging) to unknowingly authenticate against production.

Added .inspect_err() before .unwrap_or_default() to print a warning to stderr when parsing fails, while still falling back to defaults for bootstrap/recovery:

let config = storage::load_config()
    .inspect_err(|e| {
        let _ = Term::stderr().write_line(&format!(
            "Warning: Config file has errors, using default settings: {e}"
        ));
    })
    .unwrap_or_default();

Closes #307

Link to Devin session: https://app.devin.ai/sessions/c760784c0c454dd096c8def6f4406ec6
Requested by: @sachiniyer

---

---

Summary by cubic

Warn on config parse errors during auth login by printing to stderr before falling back to defaults. Prevents silent fallback that could make users with custom api_url/app_url authenticate against production.

^{Written for commit cc28dc7. Summary will update on new commits.}

[devin-ai-integration]

Original prompt from Sachin

Fix GitHub issue #307 in usedetail/cli: "CLI Auth: auth login silently falls back to production URLs when config is invalid"

#``# Repository
usedetail/cli (https://github.com/usedetail/cli)

#``# Bug
In the auth login command, storage::load_config().unwrap_or_default() silently falls back to production URLs when config parse errors occur. Users who configured custom api_url or app_url settings (e.g., for staging) will unknowingly authenticate against production instead.

#``# Fix
Add a warning when config parsing fails in the auth login path, while still defaulting to allow bootstrap/recovery:

let config = storage::load_config()
    .inspect_err(|e| {
        let _ = Term::stderr().write_line(&format!(
            "Warning: Config file has errors, using default settings: {e}"
        ));
    })
    .unwrap_or_default();

Find the auth login handler (likely in src/commands/auth.rs or src/lib.rs) where storage::load_config().unwrap_or_default() is called in the AuthCommands::Login match arm.

#``# Requirements

1. Add .inspect_err() to warn users when config parsing fails during auth login
2. Ensure the warning goes to stderr so it doesn't break machine-readable output
3. Ensure all existing tests still pass (cargo test)
4. Ensure cargo fmt --check and cargo clippy -- -D warnings pass
5. Create a PR that closes #307

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[aviator-app]

Current Aviator status

Aviator will automatically update this comment as the status of the PR changes.
Comment /aviator refresh to force Aviator to re-examine your PR (or learn about other /aviator commands).

This PR was merged manually (without Aviator). Merging manually can negatively impact the performance of the queue. Consider using Aviator next time.

---

See the real-time status of this PR on the Aviator webapp.

Use the Aviator Chrome Extension to see the status of your PR within GitHub.

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

📝 Info: Inconsistent config error handling across call sites

The PR adds a user-facing warning when load_config() fails in the Login handler, but the other call site in src/lib.rs:74 (create_client) propagates the error with ? instead. This means a corrupted config causes auth login to silently fall back to defaults (now with a warning), while auth status and all other commands using create_client() will hard-fail. This is intentional — login needs to work even with a broken config so the user can re-authenticate — but it's worth noting the asymmetry.

---

Was this helpful? React with 👍 or 👎 to provide feedback.