Struggling with Hub/sync/several devices

I have atuin on macOS, and on several Linux machines.

This rabbithole started when I set up a new machine today, installed atuin… and accidentally (!) discovered Atuin Hub, which I think was the default login option. Anyway, I installed on a new machine, and wanted to sync with my other machines. This is Linux machine A.

On my original (macOS) machine - with the original key - I admit I had not upgraded for a while. I just updated atuin, and linked to Hub.

Now, I’m trying to convert my legacy login to Hub:

$ atuin login                                      
You have a legacy sync session. Continuing login to upgrade to full Hub authentication.
IMPORTANT
If you are already logged in on another machine, you must ensure that the key you use here is the same as the key you used there.
You can find your key by running ‘atuin key’ on the other machine.
Do not share this key with anyone.

Read more here: 

Please enter encryption key [blank to use existing key file]: [my key]
Error: Failed to request authentication code from Hub

Caused by:
0: error sending request for url (https://hub.atuin.sh/auth/cli/code)
1: client error (Connect)
2: tls handshake eof

Location:
crates/atuin-client/src/hub.rs:273:16

doctor output:

{
  "atuin": {
    "version": "18.16.1",
    "commit": "671f96b60dac49d1d2de73cc0812986a5e22ce7b",
    "sync": {
      "auth_state": "Hub (legacy token — run 'atuin login' to upgrade)",
      "records": true,
      "auto_sync": true,
      "last_sync": "2026-05-19 20:33:01.041093 +00:00:00"
    },
    "sqlite_version": "3.46.0"
  },
  "shell": {
    "name": "zsh",
    "default": "zsh",
    "plugins": [
      "atuin"
    ],
    "preexec": "built-in"
  },
  "system": {
    "os": "Darwin",
    "arch": "arm64",
    "version": "26.5",
    "disks": [
      {
        "name": "Macintosh HD",
        "filesystem": "apfs"
      },
      {
        "name": "Macintosh HD",
        "filesystem": "apfs"
      }
    ]
  }
}

On my daily driver Linux machine B, I’m unable to join the dots:

$ atuin account link
Found both Hub and CLI sessions. Linking accounts...
Successfully linked CLI account to Hub.
$ atuin sync

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

✗

Wrong encryption key

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


  Your local encryption key cannot decrypt the data on the server. This usually means another
  machine wrote records with a different key.
  
  To fix this, find the correct key by running `atuin key` on a machine that already syncs
  successfully, then run `atuin store rekey <key>` here.

$ atuin login
You are authenticated with Atuin Hub.
Run 'atuin logout' to log out.
$ atuin store rekey "[my key]"
Re-encrypting store with specified key
Error: attempting to decrypt with incorrect key. currently using [enc-key-a], expecting [enc-key-b]

Location:
    crates/atuin-client/src/record/encryption.rs:132:9

doctor output from Linux machine B

{
  "atuin": {
    "version": "18.16.1",
    "commit": "671f96b60dac49d1d2de73cc0812986a5e22ce7b",
    "sync": {
      "auth_state": "Hub (authenticated)",
      "records": true,
      "auto_sync": true,
      "last_sync": "2026-05-19 19:42:26.987576968 +00:00:00"
    },
    "sqlite_version": "3.46.0"
  },
  "shell": {
    "name": "zsh",
    "default": "zsh",
    "plugins": [
      "atuin"
    ],
    "preexec": "built-in"
  },
  "system": {
    "os": "Fedora Linux",
    "arch": "x86_64",
    "version": "44",
    "disks": [
      {
        "name": "/dev/nvme0n1p3",
        "filesystem": "btrfs"
      },
      {
        "name": "/dev/nvme0n1p2",
        "filesystem": "ext4"
      },
      {
        "name": "/dev/nvme0n1p3",
        "filesystem": "btrfs"
      },
      {
        "name": "/dev/nvme0n1p1",
        "filesystem": "vfat"
      }
    ]
  }
}

So to me it looks like I’ve got three separate installs here, and I’m not able to have them all logged in and using the same (original - from macOS) key.

I’m not seeing references to the 0: error sending request for url (https://hub.atuin.sh/auth/cli/code) error on GitHub. Is something down? Can I get any additional debugging output? Previously a couple of years back I was able to use ATUIN_LOG=debug to tease more verbose information out, but that isn’t making a difference here now.

Help?

Hey! Sorry you’re running into this! I think there’s two distinct issues here

  1. Something happening with connections to the hub on machine B
  2. Issues with mixed keys in your local store. We only recently started checking for this, and previously it could silently cause errors

Connection issues

I can’t find any serverside issues here - are you able to curl https://hub.atuin.sh at all? I’m wondering if there’s something up with our tls stuff on your system. It isn’t urgent that you migrate to a hub key, realistically the old one will work as auth for a long time yet.

The lack of debug logging is a regression I will push a fix up for shortly - we reworked a lot of the client code to run via the daemon, and logging is only setup properly on that path right now.

Encryption key issues

Previously, we never checked that the key you supplied matched what was in the remote store. This meant that under certain circumstances, it was possible to end up with a “mixed store” - ie, your records are encrypted with different keys and cannot sync across all devices. I suspect this is what happened in your case, and is only now being exposed.

If you could first let me know if all devices you’re using have the same key (use atuin key to check). Obviously don’t share the key here, but let me know which machines (if any) have matching keys and I can share the command you’ll need to fix the situation!

We’re actively working on the UX here, our key management hasn’t been the easiest thing to get right for a while now.

Asks

For each machine, please share

  1. The key in use (do not share the key, let me know if it matches any other machine)
  2. If atuin login is successful
  3. If atuin sync is successful
  4. The output of atuin store verify