fix(cli): prefer user/api audience for mixed-aud JWTs

[SergioChan]

Summary

• handle JWT aud claims as an ordered set instead of trusting the first item in an array
• prioritize api-token-auth.chainloop and user-auth.chainloop ahead of generic chainloop when multiple audiences are present
• add a regression test for mixed-audience user tokens (["chainloop", "user-auth.chainloop"]) so user identity is selected instead of issuer fallback

Testing

• go test ./app/cli/internal/token

Related

• Fixes ERR failed to load issuer: authorization error: issuer not found: cp.chainloop #2812

[cubic-dev-ai]

No issues found across 2 files

[SergioChan]

Thanks for the checks — I force-pushed an amended commit with DCO sign-off so the DCO status should now pass.

No functional code changes were introduced in this push.

[migmartri]

Thanks for the contribution

Could you elaborate on what was the root cause of the problem?

Thanks

[SergioChan]

Thanks for the detailed review feedback 鈥?I鈥檓 working through the requested updates and will post a focused patch (or direct answers) shortly.

[SergioChan]

Thanks for the detailed review feedback 鈥?I鈥檓 working through the requested updates and will post a focused patch (or direct answers) shortly.

[SergioChan]

Thanks for asking — root cause was in the CLI audience selection logic, not tmux itself.

Before this patch, we effectively trusted the first value when aud was an array. For affected user tokens the audience list can be mixed, e.g. ["chainloop", "user-auth.chainloop"], where the generic chainloop value may appear before the specific auth audience.

That caused the CLI to classify the token via the generic audience path and then fall back to issuer resolution (cp.chainloop), which is where the issuer not found: cp.chainloop error came from.

The fix changes audience handling to treat aud as a set and apply explicit priority (api-token-auth.chainloop / user-auth.chainloop before generic chainloop) so mixed-audience user tokens are classified correctly.

[migmartri]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[Piskoo]

The issue mentions a possible race condition between tmux sessions affecting the local config. Does this fix address the root cause? Consider adding a negative case for a multi-audience token where none match the known audiences (["unknown1", "unknown2"] → returns nil).

[SergioChan]

Good callout — thank you.

Short answer: this PR addresses the audience-selection bug in mixed-aud tokens (which surfaced as the issuer not found: cp.chainloop behavior), not tmux session coordination itself.

I’ll add the negative multi-audience case you suggested ([unknown1, unknown2] -> nil) and push an update.