The argocd CLI speaks native gRPC (HTTP/2) by default, and your ingress, load balancer, or proxy in front of the Argo CD server does not pass HTTP/2 through - so the call dies before auth even starts. Re-run with argocd login --grpc-web [server]; the flag persists in the CLI config, so later commands keep working.

## The error
```text
FATA[0001] Failed to invoke grpc call. Use flag --grpc-web to connect to the Argo CD server
```

## What to do
1. Log in with gRPC-Web:
```bash
argocd login [server] --grpc-web --username [user]
```
   Expected: Login succeeds; context saved.
2. Confirm later commands work without re-passing the flag:
```bash
argocd app list
```
   Expected: Lists applications.
3. If it still fails behind AWS ALB, confirm the target group protocol is HTTPS, not gRPC.
   Expected: ALB routes the tunneled calls correctly.

## When this applies
- the exact Failed to invoke grpc call message
- Argo CD behind nginx/ALB/Cloudflare ingress
- argocd CLI on networks that break HTTP/2

## When it does NOT apply
- Invalid username or password (auth, not transport)
- rpc Unauthenticated (token expired - relogin instead)

## Works with
argocd CLI 2.x/3.x

### rpc error: code = Unavailable desc = connection refused (same setup)
Same broken-transport family. Try --grpc-web before debugging auth.

## Why it happens
Native gRPC needs end-to-end HTTP/2 with trailers. Most ingress controllers and L7 load balancers terminate or mangle that; gRPC-Web tunnels the same RPCs over plain HTTP/1.1 POSTs, which every proxy passes.

## Edge cases
- --grpc-web is stored per server context in ~/.config/argocd/config - a fresh login without it on the same server re-breaks.
- Port-forwarded argocd-server (kubectl port-forward) usually does not need the flag; the ingress path does.

## Resolved from
computingforgeeks argocd CLI guide - https://computingforgeeks.com/argocd-cli-complete-guide/