Sessions are their own record
A CLI login is a chain of refresh tokens that rotate on every use. Fabro previously stored the identity and profile on each token in that chain, so the chain itself had no record of its own. It now does: anauth_sessions row per login, with its tokens in refresh_tokens, both in <storage_root>/db/fabro.sqlite3.
Two dates on Settings → Sessions were wrong as a result and are now correct. A session’s created date came from its newest token, so it moved forward every time the CLI refreshed, and last seen showed the same value rather than the last time the session was actually used.
Listing and revoking sessions no longer reads every refresh token the server has ever issued, so both stay fast as a workspace accumulates logins. Revoking a session removes its tokens in the same operation.
Pending CLI logins
Pending CLI authorization codes now live in SQLite as SHA-256 hashes and are consumed atomically on the first exchange attempt. A login that is already between browser approval and token exchange when the server upgrades cannot carry across the storage cutover; runfabro auth login again. These codes expire after 60 seconds, and completed logins are unaffected.
Refresh token replay
Replaying a refresh token still revokes its whole chain immediately. One detail changed: when several requests present the same already-rotated token at once, later ones now reportrefresh_token_expired where they previously reported refresh_token_revoked. The CLI treats both the same way — it discards the stored credentials and prompts you to sign in again.
More
Fixes
Fixes
fabro validatenow stays offline and no longer requires a server model catalog- Child agents now share the parent task runtime across every model profile