fix(cli): refresh the CAS upload token before it expires

[jiparis]

The CAS upload token expires 30 seconds after the control plane issues it. The CLI requested the token before it crafted a material. When crafting took longer than 30 seconds, the upload failed with a "JWT expired" error. Secret redaction of big AI coding sessions (#3368) is one example: it can take minutes.

This change makes the CLI get the CAS token when each upload starts:

• grpcconn has a new WithTokenProvider option. The connection asks the provider for the bearer token on each call.
• The CLI caches the CAS token. If the cached token expires in less than 10 seconds, the CLI requests a new token from the control plane.

The crafter and the CAS client are unchanged.

Fixes PFM-7428

AI disclosure: this change was produced with the assistance of Claude Code.

[chainloop-platform]

AI Session Checks — 🟢 87% · ✅ 0 failing

Avg score	Sessions	Failing policies	Attribution	Files	Lines	Total Duration
🟢 87%	1	✅ 0	100% AI / 0% Human	5	+298 / -5	38m31s

🟢 87% — 100% AI — ✅ All policies passing

Sep 25, 2026 09:22 UTC · 38m31s · $3.18 · 136 in / 36.6k out · claude-code 2.1.282 (claude-opus-5-5)

View session details ↗

Change Summary

• Updates the CLI CAS upload path to fetch bearer tokens per request instead of once before crafting.
• Adds a cached token source that refreshes close-to-expiry upload tokens from GetUploadCreds.
• Adds tests for token refresh decisions and a local gRPC check that each call sends a fresh token.

AI Session Overall Score

🟢 87% — Strong root-cause fix, but verification stopped short of reproducing the real upload failure.

AI Session Analysis Breakdown

🟢 95% · user-trust-signal

No notes.

🟢 94% · scope-discipline

🟢 The code changes stayed inside the CLI upload path and grpc token plumbing. · High Impact

🟢 92% · alignment

No notes.

🟢 91% · solution-quality

🟢 AI chose per-request refresh instead of the weaker longer-token workaround. · High Impact

🟢 86% · context-and-planning

No notes.

🟡 74% · verification

🟢 AI added token tests, a local gRPC check, and a race run. · High Impact

🟠 Tests passed, but the real control-plane-to-CAS failure path was not rerun. · Medium Severity

💡 When the bug is reproducible end to end, rerun that path once before declaring the fix done.

🟡 The active user never confirmed the repaired upload behavior in-session. · Low Severity

---

File Attribution

████████████████████ 100% AI / 0% Human

Status	Attribution	File	Lines
created	ai	app/cli/pkg/action/cas_token_test.go	+111 / -0
created	ai	app/cli/pkg/action/cas_token.go	+73 / -0
modified	ai	pkg/grpcconn/grpcconn_test.go	+69 / -0
modified	ai	pkg/grpcconn/grpcconn.go	+28 / -4
modified	ai	app/cli/pkg/action/action.go	+17 / -1

---

Policies (4)

Status	Policy	Material	Messages
✅ Passed	ai-config-ai-agents-allowed	ai-coding-session-a2cde4	-
✅ Passed	ai-config-no-dangerous-commands	ai-coding-session-a2cde4	-
✅ Passed	ai-config-no-secrets	ai-coding-session-a2cde4	-
✅ Passed	ai-config-mcp-servers-allowed	ai-coding-session-a2cde4	-

---

PR validation — ✅ 3 passing

Status	Policy	Material	Messages
✅ Passed	pr-min-approvals	pr-info	-
✅ Passed	pr-description-required	pr-info	-
✅ Passed	pr-user-story-linked	pr-info	-

View attestation ↗

---

Powered by Chainloop and Chainloop Trace

[cubic-dev-ai]

No issues found across 5 files

_{Re-trigger cubic}