hzhang 2176383729 fix(cli): send api-keys via X-API-Key in client.New + help surface ...

passmgr.GetToken returns an api-key in padded-cell mode (provisioned by
scripts/provision-hf-accounts.sh via 'hf user reset-apikey'), but every
call site funneled that through client.New which sent it as a
'Authorization: Bearer <hex>'. The HF backend's HTTPBearer middleware
expects JWT shape there and rejects hex strings as 'Could not validate
credentials'. The d2b83ad backend fix added a Bearer-fallback that tries
the value as an api-key, which masked the issue against current prod;
older backends or any future change in that fallback still 401.

Two changes:
- client.New auto-detects shape: 'eyJ'-prefix + two dots == JWT (Bearer),
  anything else == api-key (X-API-Key). Empty token sets neither header.
- internal/help/surface.go's loadPermissionState (called by hf --help
  introspection) switches to client.NewWithAPIKey explicitly so the
  command-discovery path doesn't depend on the heuristic at all. When
  that path failed silently (Known:false), agents would see only the
  always-permitted commands ('user.*', 'agent.status', 'config',
  'health', 'version') and conclude they had no project permission.

Adds internal/client/client_test.go covering both header paths plus
empty-token, isLikelyJWT cases, and NewWithAPIKey precedence.

Verified end-to-end in sim against a rebuilt hf-backend matching prod
(commit d2b83ad): cli with --token <api-key> sends X-Api-Key header,
backend returns 200 on /projects + /auth/me/permissions.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-26 12:43:04 +01:00

12 KiB

Raw Blame History

View Raw