keryx auth refresh¶

Description¶

Keep unattended posting alive: refresh/rotate each platform's tokens where it can, and alert where it can't (spec 0010-auth-refresh.md). Run it on a schedule in the owning project, well inside each token's window — a silently stale token is the top unattended failure mode.

Per platform, by token shape:

It is side-effecting (writes tokens) and so is gated off the MCP surface.

Usage¶

keryx auth refresh [<platform>|all] [--dry-run]

• keryx auth refresh / keryx auth refresh all — every enabled platform (the CI entrypoint).
• keryx auth refresh tiktok — one platform.
• --dry-run — report each platform's token status + the action it would take; change nothing.

Exits non-zero if any platform needs attention (so a scheduled pipeline goes red), and fires the configured alert backend.

Configuration¶

Both backends are config-selected (auth.*), like keryx's generation providers:

auth:
  writeback:
    backend: local        # local (keychain/config) | gitlab (CI variable API — Phase 2)
  alerts:
    backend: none         # none (red pipeline only) | webhook (Slack/Teams; ALERT_WEBHOOK_URL)

Secrets are resolved as for posting (env → keychain → config); the same client ids/secrets the adapters use (TIKTOK_CLIENT_SECRET, YOUTUBE_CLIENT_SECRET, INSTAGRAM_APP_SECRET, LINKEDIN_CLIENT_SECRET) are needed to refresh.

Flags¶

Scheduling¶

keryx is stateless — the schedule lives in the owning project's CI (a weekly scheduled pipeline running keryx auth refresh all with auth.writeback.backend set for that environment). See spec 0010 §8.