cronoclient.NewLoggedIn (called from every export subcommand's RunE) performs a full username/password authenticate + token exchange against Cronometer on every CLI invocation. There is no session/token cache, so a normal LLM-agent workflow that fires 3–5 commands in a row (e.g. the very pattern prime recommends — nutrition --since today, servings --since today, biometrics --since 30d, ...) trips Cronometer's "Too Many Attempts" throttle.
Reproduced during QA: about 6 back-to-back commands was enough to lock the account for several minutes, after which every command fails with:
$ /tmp/crono-export biometrics --since 90d --format json
error: login failed: login failed: {"error":"Too Many Attempts. Please try again later."}
(Bonus: the message is double-wrapped — cronoclient/client.go:30 wraps cronoapi/client.go:144, both with the prefix login failed:. Worth cleaning up while we're in there.)
Proposal: on-disk token cache
- After a successful login, persist the session cookies / authorization token to
~/.cache/crono-export/session.json with mode 0600 (respect XDG_CACHE_HOME when set).
- On the next invocation, load the cached session and try the request directly. If the request returns 401/auth-failed, drop the cache, re-login, retry once.
- Escape hatches:
CRONOMETER_NO_CACHE=1 env var to force per-invocation login (parity with today's behavior).crono-export auth logout subcommand that nukes the cache file.
- Document the cache path + invalidation behavior in
prime and the README.
This keeps the env-var-only credential model (no password ever written to disk) while making the per-command path cheap, fast, and rate-limit-friendly for the agent workflow the tool is built for.
Out of scope (separate issues if we want them)
- Client-side backoff when we do see "Too Many Attempts" — useful but doesn't fix the root cause.
- Better error message when the throttle hits (mention cache + suggest waiting).
Severity: major (blocks the documented agent workflow within a single chat session)
cronoclient.NewLoggedIn(called from every export subcommand'sRunE) performs a full username/password authenticate + token exchange against Cronometer on every CLI invocation. There is no session/token cache, so a normal LLM-agent workflow that fires 3–5 commands in a row (e.g. the very patternprimerecommends —nutrition --since today,servings --since today,biometrics --since 30d, ...) trips Cronometer's "Too Many Attempts" throttle.Reproduced during QA: about 6 back-to-back commands was enough to lock the account for several minutes, after which every command fails with:
(Bonus: the message is double-wrapped —
cronoclient/client.go:30wrapscronoapi/client.go:144, both with the prefixlogin failed:. Worth cleaning up while we're in there.)Proposal: on-disk token cache
~/.cache/crono-export/session.jsonwith mode0600(respectXDG_CACHE_HOMEwhen set).CRONOMETER_NO_CACHE=1env var to force per-invocation login (parity with today's behavior).crono-export auth logoutsubcommand that nukes the cache file.primeand the README.This keeps the env-var-only credential model (no password ever written to disk) while making the per-command path cheap, fast, and rate-limit-friendly for the agent workflow the tool is built for.
Out of scope (separate issues if we want them)
Severity: major (blocks the documented agent workflow within a single chat session)