# How to Configure an API Key for CodeWhale Using `codewhale login` > Learn how to configure your API key for CodeWhale with the `codewhale login` command. Securely store your credentials in `~/.codewhale/config.toml` and the OS keyring. - Repository: [Hunter Bown/CodeWhale](https://github.com/Hmbown/CodeWhale) - Tags: how-to-guide - Published: 2026-06-02 --- **The `codewhale login` command stores your API key in `~/.codewhale/config.toml` and the OS keyring, defaulting to the DeepSeek provider unless you specify otherwise.** The **Hmbown/CodeWhale** CLI provides a unified authentication system for multiple LLM providers. Understanding how to configure an API key for CodeWhale using `codewhale login` ensures your credentials are securely persisted and immediately available for code generation workflows. ## Understanding the `codewhale login` Command Architecture The `codewhale login` syntax functions as a legacy alias for the modern `codewhale auth set` command. According to the implementation in [`crates/cli/src/lib.rs`](https://github.com/Hmbown/CodeWhale/blob/main/crates/cli/src/lib.rs) (lines 79-107), the command handles provider resolution, key acquisition, and secure persistence in a single operation. When you execute the login command, the CLI performs three sequential actions: it resolves the provider (defaulting to DeepSeek via `args.provider.unwrap_or(ProviderArg::Deepseek)`), acquires the API key from flags or STDIN, and writes the credential to both the configuration file and the OS keyring. ## Configuring Your API Key ### Using the Legacy Login Command For quick configuration with the default DeepSeek provider, use the legacy syntax: ```bash codewhale login --api-key "sk-deepseek-xxxxxxxxxxxx" ``` If you omit the `--api-key` flag, the CLI reads the value from STDIN, allowing you to paste the key securely without exposing it in your shell history. ### Using the Modern Auth Command (Recommended) For explicit provider selection and better forward compatibility, use the `auth set` subcommand: ```bash codewhale auth set --provider openai --api-key "sk-openai-xxxxxxxxxxxx" ``` Available providers include `deepseek`, `openai`, `nvidia-nim`, and `atlascloud`. This approach eliminates ambiguity about which backend receives your credentials and is the preferred method for multi-provider workflows. ### Verifying the Stored Credential After configuration, confirm the active credential source without exposing the full secret: ```bash codewhale auth status ``` This outputs the provider name, key source (keyring, config file, or environment variable), and the last four digits of the stored key. ## How CodeWhale Stores Your Credentials CodeWhale implements a dual-storage strategy defined in [`crates/cli/src/lib.rs`](https://github.com/Hmbown/CodeWhale/blob/main/crates/cli/src/lib.rs) (lines 95-100). Your API key is written to **`~/.codewhale/config.toml`** for configuration portability and simultaneously saved to the **OS keyring** for encrypted, secure retrieval. On first launch, the CLI automatically migrates legacy configurations from `~/.deepseek/config.toml` to the new unified location, as documented in [`docs/CONFIGURATION.md`](https://github.com/Hmbown/CodeWhale/blob/main/docs/CONFIGURATION.md) (lines 74-78). This migration ensures users upgrading from earlier versions retain their credentials without manual file manipulation. ## Complete Configuration Examples Configure multiple providers for different backend workflows: ```bash # Store DeepSeek key using legacy syntax codewhale login --api-key "sk-deepseek-abc123" # Store OpenAI-compatible key using modern syntax codewhale auth set --provider nvidia-nim --api-key "nvapi-xyz789" # Verify authentication status codewhale auth status ``` Expected output: ``` Provider: nvidia-nim Key source: keyring (last 4 digits: ****7890) Config file: /home/you/.codewhale/config.toml ``` ## Summary - **`codewhale login`** is a legacy alias that defaults to the DeepSeek provider and persists keys to both `~/.codewhale/config.toml` and the OS keyring. - **Explicit provider selection** via `codewhale auth set --provider ` is the recommended approach for production workflows. - Keys are **acquired from flags or STDIN**, then stored using the logic implemented in [`crates/cli/src/lib.rs`](https://github.com/Hmbown/CodeWhale/blob/main/crates/cli/src/lib.rs). - Use **`codewhale auth status`** to verify credential sources without exposing sensitive data. - The CLI **auto-migrates** legacy `~/.deepseek/config.toml` files to the new unified config location on first run. ## Frequently Asked Questions ### What is the default provider when using `codewhale login`? The default provider is **DeepSeek**. According to the source code in [`crates/cli/src/lib.rs`](https://github.com/Hmbown/CodeWhale/blob/main/crates/cli/src/lib.rs) (lines 88-90), the CLI resolves the provider argument using `args.provider.unwrap_or(ProviderArg::Deepseek)`, ensuring that bare `codewhale login` commands target the DeepSeek backend unless a different provider is explicitly specified. ### Where does CodeWhale store my API key? CodeWhale stores your API key in two locations: the shared user configuration file at **`~/.codewhale/config.toml`** and the **OS keyring** for encrypted storage. This dual-storage approach, implemented in [`crates/cli/src/lib.rs`](https://github.com/Hmbown/CodeWhale/blob/main/crates/cli/src/lib.rs) (lines 95-100), ensures credentials survive configuration backups while remaining encrypted at rest. ### How do I switch from `codewhale login` to the modern authentication command? Replace `codewhale login --api-key ""` with `codewhale auth set --provider --api-key ""`. The login command remains functional as a legacy alias, but the explicit syntax provides clearer intent and supports multiple providers beyond DeepSeek. ### Can I verify my API key configuration without exposing the full key? Yes. Run **`codewhale auth status`** to display the active provider, the credential source (keyring, config file, or environment variable), and only the last four digits of the stored key. This allows you to confirm successful authentication without printing sensitive information to the terminal.