atuin/crates/atuin-client/src/record, branch main

chore: Move everything into one big crate

2026-06-10T22:54:30Z

That helps remove duplicated code and rustc/cargo will now also show dead code correctly.

chore: Turn all `allow`s into into `expect`s

2026-06-10T20:28:10Z

fix: ensure local key matches remote data before syncing (#3474)

2026-05-12T20:45:02Z

We rely on the user to manage their keys. This is ok, and is intentionally part of our security model However. If the user messes up, they corrupt their remote store. It is possible to work around and fix, but not without difficulty. This change ensures that if the local key does not match the remote data, no data is synced and the user has a chance to fix it before breaking things. ## Checks - [ ] I am happy for maintainers to push small adjustments to this PR, to speed up the review cycle - [ ] I have checked that there are no existing pull requests for the same thing

feat: Allow authenticating with Atuin Hub (#3237)

2026-03-11T15:50:17Z

## Summary This PR enables the Atuin CLI to authenticate with Atuin Hub, unifying authentication across CLI sync and Hub features (AI, runbooks, etc.). ### Key Changes - **Dual auth support**: New `AuthToken` enum supports both `Bearer` (Hub) and `Token` (legacy CLI) authentication - **Smart protocol selection**: New `sync_protocol` setting (`auto`/`hub`/`legacy`) determines auth method. By default, `api.atuin.sh` uses Hub auth; custom sync addresses use legacy auth - **Hub login flow**: `atuin login` now initiates an OAuth-like flow for Hub users—generates a code, user authorizes in browser, CLI polls for completion - **Account linking**: After Hub auth, silently attempts to link existing CLI sync account to Hub account for seamless migration - **Graceful fallback**: `sync_auth_token()` prefers Hub token when available, falls back to CLI session token ### Auth Flow 1. User runs `atuin login` (with default sync address) 2. CLI requests auth code from Hub, displays URL 3. User opens URL, logs in/registers on Hub 4. Hub attaches API token to code 5. CLI polls, receives token, saves as hub session 6. If user had existing CLI sync account, it's automatically linked ### Backward Compatibility - Existing self-hosted users: unaffected (legacy auth via `Token` header) - Existing `api.atuin.sh` users: continue working with CLI session until they run `atuin login` - New users: go through Hub flow automatically ## Test Plan - [ ] New user registration via Hub flow - [ ] Existing CLI user can still sync without changes - [ ] `atuin login` links CLI account to Hub account - [ ] Self-hosted users unaffected by changes - [ ] AI commands work after Hub auth --------- Co-authored-by: Ellie Huxtable

feat: replace several files with a sqlite db (#3128)

2026-02-04T21:26:06Z

These files have been known to have corruption issues. SQLite will perform better across filesystems for reads/writes across threads, and will lock as expected. I've also put the session file in there, though I'm 50/50 on it - I'll be replacing it with keyring storage asap anyway. The key file is _not_ included. It should ~never be changed, and should be easy for the user to secure + manage themselves In the future, instead of creating more files, we can just use this as a kv store Resolves https://github.com/atuinsh/atuin/issues/2336, resolves https://github.com/atuinsh/atuin/issues/1650 ## Checks - [ ] I am happy for maintainers to push small adjustments to this PR, to speed up the review cycle - [ ] I have checked that there are no existing pull requests for the same thing

feat: Add a parameter to the sync to specify the download/upload page (#2408)

2026-02-04T02:25:36Z

This adds a parameter to change the upload/download page size, this could help if one gets a '413' in a selfhosted scenario. ## Checks - [x] I am happy for maintainers to push small adjustments to this PR, to speed up the review cycle - [x] I have checked that there are no existing pull requests for the same thing --------- Co-authored-by: Ellie Huxtable

fix: halt sync loop if server returns an empty page (#3122)

2026-02-03T06:31:08Z

We had an issue where the server was returning an empty page, when it should not, and causing the client to keep looping While such bugs should not happen, putting the client into a loop does not help ## Checks - [ ] I am happy for maintainers to push small adjustments to this PR, to speed up the review cycle - [ ] I have checked that there are no existing pull requests for the same thing

fix: clippy warnings I don't have on my version of clippy

2025-09-10T19:57:43Z

fix: run `cargo fmt`

2025-09-10T19:57:43Z

fix: clean up new rustc and clippy warnings on Rust 1.89

2025-09-10T19:57:43Z