# argocd login: Authenticate the CLI in CI

> argocd login authenticates the CLI to an Argo CD API server. Reference for --grpc-web, --auth-token, --insecure, and the connection errors that hit CI.

Source: https://latchkey.dev/learn/command-reference/argocd-login  
Updated: 2026-06-30

argocd login <server> authenticates the CLI to an Argo CD API server and caches the session in ~/.config/argocd/config.

Every other argocd command needs an authenticated session. In CI you want it fully non-interactive with a token and password supplied on the command line.

## What it does

argocd login connects to the Argo CD API server, exchanges credentials for a session token, and writes it to the CLI config. Use --username/--password for a local account or --sso for SSO; in pipelines an API token via --auth-token is simplest.

## Common usage

```Terminal
argocd login argocd.example.com \
  --username admin --password "$ARGOCD_PASSWORD" --grpc-web
# token-based, no interactive prompt
argocd login argocd.example.com \
  --auth-token "$ARGOCD_AUTH_TOKEN" --grpc-web
```

## Options

| Flag | What it does |
| --- | --- |
| --username / --password | Local account credentials |
| --auth-token <token> | Use a pre-issued API token instead of a login |
| --grpc-web | Tunnel gRPC over HTTP/1.1 (needed behind many ingresses) |
| --insecure | Skip TLS verification of the API server |
| --plaintext | Use HTTP instead of HTTPS to the API server |

## In CI

Behind an ingress that does not support HTTP/2 trailers, add --grpc-web or every command hangs. Prefer ARGOCD_AUTH_TOKEN over a password, and set --server once via the ARGOCD_SERVER env var so later commands do not repeat it.

## Common errors in CI

"FATA[0000] rpc error: code = Unavailable desc = ... transport: ..." or a long hang usually means the server needs --grpc-web. "x509: certificate signed by unknown authority" means a self-signed API cert; add --insecure for tests or trust the CA. "FATA[0000] Username/password is empty" means the credentials env vars are unset.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### argocd login: Authenticate the CLI in CI?

Every other argocd command needs an authenticated session. In CI you want it fully non-interactive with a token and password supplied on the command line.

### What it does?

argocd login connects to the Argo CD API server, exchanges credentials for a session token, and writes it to the CLI config. Use --username/--password for a local account or --sso for SSO; in pipelines an API token via --auth-token is simplest.

### In CI?

Behind an ingress that does not support HTTP/2 trailers, add --grpc-web or every command hangs. Prefer ARGOCD_AUTH_TOKEN over a password, and set --server once via the ARGOCD_SERVER env var so later commands do not repeat it.

### Common errors in CI?

"FATA[0000] rpc error: code = Unavailable desc = ... transport: ..." or a long hang usually means the server needs --grpc-web. "x509: certificate signed by unknown authority" means a self-signed API cert; add --insecure for tests or trust the CA. "FATA[0000] Username/password is empty" means the credentials env vars are unset.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt