Context
Authentication is keyring-only, which fails in CI, containers, and headless Linux hosts without a Secret Service. The config layer already hints at env-based auth but nothing consumes it, so there is no way to run cu non-interactively.
Evidence
- The config struct declares an
api_token mapstructure field and viper is configured with AutomaticEnv and the CU prefix, so CU_API_TOKEN is read into config — but no code path ever uses it for authentication.
internal/auth/auth.go — token retrieval goes exclusively through the OS keyring (GetToken/GetCurrentToken); on headless Linux without a Secret Service daemon this errors out with no fallback.
Suggested fix
In GetCurrentToken() (after the keyring lookup fails, i.e. lower precedence than stored credentials), fall back to the CU_API_TOKEN environment variable. Document the precedence order (keyring first, env var fallback) in the auth docs, matching the common CLI convention (GITHUB_TOKEN for gh, etc.).
Context
Authentication is keyring-only, which fails in CI, containers, and headless Linux hosts without a Secret Service. The config layer already hints at env-based auth but nothing consumes it, so there is no way to run
cunon-interactively.Evidence
api_tokenmapstructure field and viper is configured withAutomaticEnvand theCUprefix, soCU_API_TOKENis read into config — but no code path ever uses it for authentication.internal/auth/auth.go— token retrieval goes exclusively through the OS keyring (GetToken/GetCurrentToken); on headless Linux without a Secret Service daemon this errors out with no fallback.Suggested fix
In
GetCurrentToken()(after the keyring lookup fails, i.e. lower precedence than stored credentials), fall back to theCU_API_TOKENenvironment variable. Document the precedence order (keyring first, env var fallback) in the auth docs, matching the common CLI convention (GITHUB_TOKENforgh, etc.).