Summary

When running an attestation command (e.g. chainloop attestation init) with an expired user token in user-attended mode, the CLI surfaces a misleading error instead of telling the user their token has expired.

Other (non-attestation) commands such as chainloop workflow ls correctly report the expiry. The attestation flow does not.

Steps to reproduce

1. Authenticate as a user (chainloop auth login) and let the user token expire.
2. Run an attestation command:

chainloop att init --project software-project --workflow binskim 

Actual behavior

WRN User-attended mode detected. This is intended for local testing only. For CI/CD or automated workflows, please use an API token.
This command will run against the organization "test"
Please confirm to continue y/N
y
ERR failed to load issuer: authorization error: no issuers configured

Running a regular command right after, with the same expired token, reports the expiry correctly:

$ chainloop workflow ls
ERR your authentication token has expired, please run chainloop auth login again

Expected behavior

The attestation command should report the same clear, actionable message as other commands:

ERR your authentication token has expired, please run "chainloop auth login" again

Likely root cause

Attestation commands (attestation init/add/push/status/reset) are annotated with supportsFederatedAuth (app/cli/cmd/attestation_init.go, app/cli/cmd/root.go). For these endpoints the control plane resolves identity through the machine-identity / federated path. When the presented JWT is an expired user token, that path fails with failed to load issuer: ... no issuers configured (from the platform MachineIdentityUseCase.loadIssuerFromPool) rather than returning the standard ErrTokenExpired.

The CLI error mapping in app/cli/main.go only translates the expiry into a friendly message when it can match jwtMiddleware.ErrTokenExpired. Since the federated path masks the expiry as an unrelated authorization error, the CLI falls through to the generic isUnmatchedAuthErr fallback (authentication error: %s) and prints the misleading "no issuers configured" message.

The expired-token condition should be detected and reported with the proper message even on federated-auth-enabled endpoints, instead of being shadowed by the machine-identity issuer-resolution error.

Notes

• This is a UX/error-reporting bug; the request is correctly rejected, but the message does not help the user understand what to do.

🤖 Posted by Maximus bot (Claude Code) on behalf of @migmartri