`gws auth status` doesn't show when env vars override `client_secret.json`

[KRRT7]

Summary

When GOOGLE_WORKSPACE_CLI_CLIENT_ID and GOOGLE_WORKSPACE_CLI_CLIENT_SECRET environment variables are set, they silently override ~/.config/gws/client_secret.json for authentication. However, gws auth status still reports credential_source: "client_secret.json" and shows the correct config_client_id from the file — giving no indication that env vars are actually being used.

This makes it extremely difficult to debug when the env vars contain stale or deleted OAuth credentials, since every diagnostic command points to the (correct) config file while auth silently uses the (broken) env vars.

Steps to Reproduce

1. Create a valid ~/.config/gws/client_secret.json with a working OAuth client
2. Set env vars to a different (or deleted) client:

   export GOOGLE_WORKSPACE_CLI_CLIENT_ID="deleted-id.apps.googleusercontent.com"
   export GOOGLE_WORKSPACE_CLI_CLIENT_SECRET="old-secret"

3. Run gws auth status — it shows credential_source: "client_secret.json" and the correct config_client_id from the file
4. Run gws auth login — it uses the env var client ID, not the config file one, resulting in Error 401: deleted_client

Expected Behavior

• gws auth status should show credential_source: "environment" when env vars are active
• gws auth login should log which credential source it resolved to (env vars vs config file)
• Ideally, gws auth status should show both env_client_id and config_client_id when env vars are set, making the override visible

Relevant Code

In resolve_client_credentials(), env vars take priority:

let env_id = std::env::var("GOOGLE_WORKSPACE_CLI_CLIENT_ID").ok();
let env_secret = std::env::var("GOOGLE_WORKSPACE_CLI_CLIENT_SECRET").ok();
if let (Some(id), Some(secret)) = (env_id, env_secret) {
    let project_id = crate::oauth_config::load_client_config().ok().map(|c| c.project_id);
    return Ok((id, secret, project_id));
}

But gws auth status doesn't reflect this resolution order — it always reports the config file as the source.

Environment

• gws version: 0.22.5
• OS: macOS 15, Apple Silicon (arm64)

[KRRT7]

Correction — Root cause was stale environment variables, not the npm binary

After further investigation, the root cause of the deleted_client error was not the npm binary hardcoding the client ID. The actual issue was stale environment variables overriding the config file.

What happened

I had previously set GOOGLE_WORKSPACE_CLI_CLIENT_ID and GOOGLE_WORKSPACE_CLI_CLIENT_SECRET in my ~/.zshrc pointing to an OAuth client that was later deleted from Google Cloud Console. Per the source code in resolve_client_credentials() (auth_commands.rs:718), env vars take priority over ~/.config/gws/client_secret.json:

let env_id = std::env::var("GOOGLE_WORKSPACE_CLI_CLIENT_ID").ok();
let env_secret = std::env::var("GOOGLE_WORKSPACE_CLI_CLIENT_SECRET").ok();
if let (Some(id), Some(secret)) = (env_id, env_secret) {
    // Uses env vars, ignores client_secret.json
    return Ok((id, secret, project_id));
}

This meant both the npm binary and the cargo-built binary used the deleted client, because both read the same env vars. The "workaround" of building from source only appeared to work because I unset the env vars in the process.

Actual fix

# Remove stale env vars from shell config
sed -i '' '/GOOGLE_WORKSPACE_CLI_CLIENT_ID/d; /GOOGLE_WORKSPACE_CLI_CLIENT_SECRET/d' ~/.zshrc

# Unset in current session
unset GOOGLE_WORKSPACE_CLI_CLIENT_ID GOOGLE_WORKSPACE_CLI_CLIENT_SECRET

After this, gws auth login correctly reads ~/.config/gws/client_secret.json and works.

Remaining UX concern

This was extremely difficult to debug because:

1. gws auth status shows credential_source: "client_secret.json" and the correct config_client_id even when env vars are silently overriding it for auth
2. The auth URL (which contains the actual client ID being used) gets truncated in most terminals, hiding which client ID is being sent to Google
3. There's no log or warning indicating that env vars are taking priority over the config file

It would be helpful if gws auth status showed credential_source: "environment" when env vars are active, or if gws auth login logged which credential source it resolved to.