Hmbown/CodeWhale · error · anyhow::Error

`codewhale account` does not accept the global `--api-key`…

Error message

`codewhale account` does not accept the global `--api-key` flag because command-line values can leak through shell history. Use `account keys set <provider>` for a hidden prompt, `--api-key-stdin`, or `--from-local`

What it means

The `codewhale account` command group refuses the global `--api-key` flag entirely. Passing a provider API key on the command line risks leaking it into shell history and process listings, so the CLI rejects any invocation where api_key is Some and points to safer input paths: the hidden prompt, stdin, or local config.

Solutions

Remove `--api-key` from the command line.
Run `codewhale account keys set <provider>` to enter the key at a hidden prompt.
Pipe the key via `--api-key-stdin` (e.g. printf %s "$KEY" | codewhale account ... --api-key-stdin).
Use `--from-local` to reuse an already-stored local key.

Example fix

// before
codewhale --api-key $KEY account keys set anthropic
// after
printf %s "$KEY" | codewhale account keys set anthropic --api-key-stdin

Defensive patterns

Strategy: validation

Validate before calling

// Scrub the global flag before invoking `codewhale account`
let args: Vec<String> = std::env::args().collect();
if args.iter().any(|a| a == "--api-key") && args.iter().any(|a| a == "account") {
    eprintln!("Pass the key via `account keys set` or --api-key-stdin instead.");
}

Prevention

Never put provider API keys on the command line — they land in shell history and ps output.
Use `codewhale account keys set <provider>` for the hidden prompt.
Use `--api-key-stdin` in scripts, fed from a secret manager.
Use `--from-local` to reuse stored local keys.

When it happens

Trigger: Invoking any `codewhale account` subcommand with the global `--api-key <value>` flag set, e.g. `codewhale --api-key sk-... account pull`.

Common situations: Users copying the global flag pattern from other codewhale commands; scripting a key inline; muscle memory from `codewhale --api-key ...` invocations of other subcommands.

Understand the failure class

Background: "Unknown argument", "Invalid value", and "must be one of": invalid CLI argument errors explained — this error's family across 35 libraries.

Related errors

AI-assisted analysis of Hmbown/CodeWhale@73e0f67d83 (2026-09-22). Data as JSON: /api/errors/a4419a4a8570aa35. Report an issue: GitHub.

Appendix: source

Thrown at crates/cli/src/cloud.rs:733

    profile: Option<&str>,
    config: &ConfigStore,
) -> Result<()> {
    run(
        CloudArgs {
            api_base: None,
            command: CloudCommand::Login(CloudLoginArgs {
                no_open,
                timeout_seconds,
            }),
        },
        profile,
        config,
    )
}

pub(crate) fn reject_inline_api_key(api_key: Option<&str>) -> Result<()> {
    if api_key.is_some() {
        bail!(
            "`codewhale account` does not accept the global `--api-key` flag because command-line values can leak through shell history. Use `account keys set <provider>` for a hidden prompt, `--api-key-stdin`, or `--from-local`"
        );
    }
    Ok(())
}

#[allow(clippy::too_many_arguments)]
fn run_with<T: CloudTransport, W: Write>(
    command: CloudCommand,
    profile: &str,
    api_base: &str,
    config: &ConfigStore,
    cloud_secrets: &Secrets,
    provider_secrets: &Secrets,
    machine: &machine::MachineKeyEnv,
    transport: &T,
    out: &mut W,
    key_reader: &mut dyn FnMut(KeyReadMode) -> Result<String>,

View on GitHub (pinned to 73e0f67d83)