Login worked, but Argo CD's own RBAC (argocd-rbac-cm) denies the action for your role - the CLI authenticated fine and the policy said no. Check what the server thinks you can do with argocd account get-user-info, then have an admin add the missing policy (e.g. applications, get, * for reads; logs need an explicit logs, get rule on 3.0+).

## The error
```text
rpc error: code = PermissionDenied desc = permission denied
```

## What to do
1. See your identity and groups:
```bash
argocd account get-user-info
```
   Expected: Shows username, groups, and capabilities.
2. Have an admin check the policy:
```bash
kubectl -n argocd get configmap argocd-rbac-cm -o yaml
```
   Expected: Shows the role policies.
3. Add the missing rule, e.g. in argocd-rbac-cm:
```
p, role:readonly, applications, get, *, allow
p, role:readonly, logs, get, *, allow
```
   Expected: Policy updated.
4. Retry the command.
   Expected: Succeeds instead of PermissionDenied.

## When this applies
- the exact PermissionDenied desc = permission denied message
- SSO users missing expected groups
- argocd 3.0+ log access that worked on 2.x

## When it does NOT apply
- Unauthenticated (not logged in / token expired)
- app is not permitted in project (AppProject scope, not RBAC)

## Works with
argocd CLI 2.x/3.x; Argo CD RBAC via argocd-rbac-cm

### pod logs forbidden on Argo CD 3.0+
3.0 enforces logs RBAC by default. Add the logs, get policy explicitly.

## Why it happens
Argo CD authorizes every API call against its own Casbin policy in argocd-rbac-cm, separate from Kubernetes RBAC. Upgrades (notably 3.0's logs enforcement) can newly deny actions that used to work.

## Edge cases
- SSO group claims must match the policy's group names exactly - empty groups in get-user-info means the IdP claim is wrong, not the policy.
- argocd admin settings rbac can checks a policy without running the command.

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