[Bug]: wrong item selected from history

[sashkab]

What did you expect to happen?

macOS 15.4.1 and atuin 18.5.0

when I press ctrl+r to find history, select item from history wrong item is pasted to the command prompt.

Can't always reproduce. Usually I do this quickly, ctrl+r, select what I need (by searching, etc) and press enter.
Few times noticed, wrong command was pasted into prompt from history.

This happened on at least two occasions just today, which already drove me a bit crazy. When specifically tried, can't reproduce.

What happened?

Wrong record was pasted into command prompt from history. let's say I wanted to select line from history where I meant to rerun command to copy file, but instead rm -rf /path which I didn't mean to delete was run.

Atuin doctor output

$ atuin doctor
Atuin Doctor
Checking for diagnostics


Please include the output below with any bug reports or issues

{
  "atuin": {
    "version": "18.5.0",
    "sync": null,
    "sqlite_version": "3.46.0"
  },
  "shell": {
    "name": "zsh",
    "default": "zsh",
    "plugins": [
      "atuin"
    ],
    "preexec": "built-in"
  },
  "system": {
    "os": "Darwin",
    "arch": "arm64",
    "version": "15.4.1",
    "disks": [
      {
        "name": "REDACTED",
        "filesystem": "apfs"
      },
      {
        "name": "REDACTED",
        "filesystem": "apfs"
      },
      {
        "name": "REDACTED",
        "filesystem": "apfs"
      }
    ]
  }
}

Code of Conduct

• I agree to follow this project's Code of Conduct

[BinaryMuse]

I've been seeing behavior like this the past few weeks, also intermittently. From my experiments, it seems like any time I select the same history entry, I get the same behavior - if selecting an entry gives me the wrong command, selecting that entry always gives me the (same) wrong command.

[lemorage]

Yes, I met exactly the same, very annoying. My current temp solution is to open a new terminal tab and then select the same history entry in the new tab.

[octylFractal]

Downgrading to 18.4.0 also doesn't fix this issue, so I assume the db itself has been written incorrectly.

[ellie]

A few questions to help narrow this down and reproduce

1. Is this when pressing enter, or when pressing tab? Or both?
2. Is there a chance history has been written to the database while the TUI is open?
3. @BinaryMuse in this case, does running atuin store rebuild history resolve the problem for that entry?
4. Does reverting to 18.3 resolve it?
5. Does setting smart_sort = false in config resolve it?

[ellie]

If anyone who can reproduce this issue is able to test #2706, I would really appreciate it!

[sashkab]

1. Is this when pressing enter, or when pressing tab? Or both?
   enter.

was able to reproduce today, but then it got missing.
sequence was:

1. press ctrl+r
2. search for command
3. select second from the bottom and press enter.
4. seems like command which was pasted was off by 1 from this command (i.e)

consider that my full history is:

....
ggpush -u 
mpv blah.mkv
rm mpv blah.mkv

ctrl+r, search for mpv, select mpv blah.mkv, ggpush -u was pasted into the command prompt.

Changing to another directory -- this problem goes away, returning to the dir -- problem comes back.

2. Is there a chance history has been written to the database while the TUI is open?
   no. single user on a system, was doing single command.

3. @BinaryMuse in this case, does running atuin store rebuild history resolve the problem for that entry?

I ran atuin store rebuild history and then tried again -- nothing changed.

4. Does reverting to 18.3 resolve it?
   didn't try yet.

6. Does setting smart_sort = false in config resolve it?
   did not change, still can reproduce.

[sashkab]

If anyone who can reproduce this issue is able to test #2706, I would really appreciate it!

are there pre-built artifacts available to try?

[edeustua]

I'm having the same issue. My far fetched guess is that my multiple terminals are syncing, and then, the history in older terminals loses sync with history indexes.

When this issue happens to me I'm usually working on two different terminals side by side. After a while, the older terminal begins having the issue. Now, if I open a new terminal, the issue is gone.

I'll post a video the next time it happens. Also, I'm going to try #2706.

[ellie]

If anyone who can reproduce this issue is able to test #2706, I would really appreciate it!

are there pre-built artifacts available to try?

I can't trivially run our release pipeline on that branch + github doesn't let me upload binaries to an issue, but you can install the code from that branch with:

cargo install --git https://github.com/atuinsh/atuin --branch ellie/attempt-fix-weird-select atuin

My far fetched guess is that my multiple terminals are syncing, and then, the history in older terminals loses sync with history indexes.

I was wondering the same. The changes in that branch couple what is displayed with what is selected more closely, so hopefully that doesn't happen. It's difficult for me to be sure without being able to replicate it, though.

[devusb]

I think it's still happening for me even with #2706 -- I was able to get a video, it's attached. Seems like it only happened for some entries though -- one reliably selected the wrong item, others were still right.

atuin-wrong-item.webm

Happy to try anything that might be helpful in narrowing this down.

[ellie]

Thank you for the video!

Does it happen if you type slower? And generally slower inputs

And does it happen on 18.3?

[devusb]

Attached another video with a brief pause before hitting enter -- doesn't seem to make a difference.
I'll switch back to 18.3 and run it for awhile to see if I can make it happen again.

atuin-wrong-item-slower.webm

[ellie]

Thanks! One more input q; if you type to filter, then press the up arrow followed by the down arrow, and then select - does it still happen?

basically want to check if this is hiding within the search logic only, or if it also affects scrolling

[devusb]

Scrolling up and down before picking doesn't seem to make a difference.

atuin-wrong-item-up-down.webm

[ellie]

ok, thanks for all the info! lmk if it still occurs with 18.3 and i can dig through the diffs.

[devusb]

will do. fwiw it feels like it just started recently (maybe with 18.5) -- I hadn't noticed it before this week, but seems like it's like 2-3 times a day now in different contexts across different machines.

[octylFractal]

To clarify my earlier comment regarding 18.4.0 -- downgrading seems to prevent the issue from occurring on new entries, as devusb said, but it doesn't seem to fix entries that are already broken, at least immediately.

[ellie]

Ohhh interesting. If you're affected by this, could you let me know what shell you're using please? output of atuin doctor would be even better.

Otherwise @octylFractal - does downgrading and then running atuin store rebuild history fix it? I doubt it will, but just ruling things out

[edeustua]

With #2706. Still happening.

atuin-issue.webm

[ellie]

With which shell?

[edeustua]

With which shell?

{
  "atuin": {
    "version": "18.5.0",
    "sync": {
      "cloud": true,
      "records": true,
      "auto_sync": true,
      "last_sync": "2025-04-20 17:55:54.576626153 +00:00:00"
    },
    "sqlite_version": "3.46.0"
  },
  "shell": {
    "name": "zsh",
    "default": "zsh",
    "plugins": [
      "atuin"
    ],
    "preexec": "built-in"
  },
  "system": {
    "os": "Arch Linux",
    "arch": "x86_64",
    "version": "rolling",
    "disks": [
      {
        "name": "/dev/nvme0n1p2",
        "filesystem": "ext4"
      },
      {
        "name": "/dev/nvme0n1p4",
        "filesystem": "ext4"
      },
      {
        "name": "/dev/sdc1",
        "filesystem": "xfs"
      },
      {
        "name": "/dev/sdb1",
        "filesystem": "xfs"
      }
    ]
  }
}

[nokernel]

@ellie

atuin store rebuild history worked for me and fixed the issue with the specific item that had trouble.

Im on atuin 18.5.0
mac 15.4.1
zsh 5.9

[monyxie]

atuin store rebuild history doesn't work for me. Linux / zsh 5.9 / atuin 18.5.0.

[octylFractal]

I hit the bug again, and tried #2715, and it seems to fix it. I did an omz reload (from oh-my-zsh), so I don't know if that might've fixed it separately since it's a per-shell issue, but I'll keep running that and see if it occurs again.

[curtisbelt]

This is happening for me too.

atuin doctor

{
  "atuin": {
    "version": "18.5.0",
    "sync": {
      "cloud": true,
      "records": true,
      "auto_sync": true,
      "last_sync": "2025-04-22 22:37:11.407481999 +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": "41",
    "disks": [
      {
        "name": "/dev/mapper/luks-0a39eede-e92f-4dda-abed-ef3ab4b0ea9a",
        "filesystem": "btrfs"
      },
      {
        "name": "/dev/mapper/luks-0a39eede-e92f-4dda-abed-ef3ab4b0ea9a",
        "filesystem": "btrfs"
      },
      {
        "name": "/dev/nvme3n1p2",
        "filesystem": "ext4"
      },
      {
        "name": "/dev/nvme3n1p1",
        "filesystem": "vfat"
      },
      {
        "name": "/dev/mapper/luks-4736d04c-0283-4c11-a228-ad70263a02d3",
        "filesystem": "btrfs"
      }
    ]
  }
}

This comment from a user above matches my experience 100%:

fwiw it feels like it just started recently (maybe with 18.5) -- I hadn't noticed it before this week, but seems like it's like 2-3 times a day now in different contexts across different machines.

As I scrolled through these comments... I tried atuin store rebuild history -- it completed without issue, but didn't seem to make any difference for this bug.

Quote from @octylFractal's comment yesterday --

I hit the bug again, and tried #2715, and it seems to fix it. I did an omz reload (from oh-my-zsh), so I don't know if that might've fixed it separately since it's a per-shell issue, but I'll keep running that and see if it occurs again.

I also use Oh My ZSH, and I just ran omz reload. This fixed it, or at least fixed it for now.

Importantly -- I am NOT using the #2715 patch. I am still on regular v18.5.

Very odd! Hope this helps...

[ellie]

Thanks @curtisbelt! So far it does seem to be only zsh users, and potentially even omz. Does suggest that #2715 might resolve it. Are you able to test the patch?

cargo install --git https://github.com/atuinsh/atuin --branch ellie/disable-zsh-changes

[ebartels]

I was also encountering this bug and came across this issue and
atuin store rebuild history has resolved the issue for me like it did here and I'm on the same version as that user.

macOS 15.4.1
atuin 18.5.0
zsh 5.9 (arm-apple-darwin21.3.0)

[ebartels]

I was also encountering this bug and came across this issue and atuin store rebuild history has resolved the issue for me like it did here and I'm on the same version as that user.

macOS 15.4.1 atuin 18.5.0 zsh 5.9 (arm-apple-darwin21.3.0)

So I noticed that in another iterm window it did not fix it even after running atuin store rebuild history again.

I'm also using omz.

I will also now install the patch to see if that resolves the issue.

[ivan-kiselev]

Thanks @curtisbelt! So far it does seem to be only zsh users, and potentially even omz. Does suggest that #2715 might resolve it. Are you able to test the patch?

cargo install --git https://github.com/atuinsh/atuin --branch ellie/disable-zsh-changes

I installed the patch yesterday, one day through will all (oh-my)-Zsh sessions opened anew, I observe no problems.

[curtisbelt]

@ellie I have the patch installed, but unfortunately, I ran into the bug again yesterday evening. I had been using the terminal (and atuin) throughout the day without seeing the bug until then. I can't think of any reason why the bug appeared again, as far as my usage pattern goes I was doing the same things I was always doing (hitting up arrow, search, hit enter to select... or hitting up arrow a couple times for recent entry, then hit enter to select) Nothing special.

omz reload fixed it again. I'm pretty sure restarting the terminal fixes it too but I'll try to test it next time.

[ellie]

Thanks for letting me know! Is there any chance that it occurred in a shell session that hadn't been restarted since installing the patched version?

[curtisbelt]

@ellie I wish that was the case! I can rule that out completely as I've restarted my computer between installing the patch and seeing the bug.

For good measure I just ran this again:

 cargo install --git https://github.com/atuinsh/atuin --branch ellie/disable-zsh-changes
    Updating git repository `https://github.com/atuinsh/atuin`
     Ignored package `atuin v18.5.0 (https://github.com/atuinsh/atuin?branch=ellie%2Fdisable-zsh-changes#b96bc5f9)` is already installed, use --force to override

which confirms it's installed.

[ebartels]

I also have the patch installed and encountered the issue again and then resolved it using omz reload so also confirming the patch is not resolving the issue.

[curtisbelt]

@ebartels @octylFractal @monyxie @nokernel
Taking a shot in the dark here - what terminal is everyone using? I'm using ghostty 1.1.2

[ellie]

@curtisbelt if i could also get the output of

atuin init zsh

just to rule out anything weird going on

If it still replicates after the patch, and still replicates on 18.3, then I'm wondering if something might have changed with omz recently. We haven't made any major changes to the zsh plugin or the interactive search in a long time, so it's strange that things aren't working now

[sashkab]

After upgrading to build from #2706 and reloading omz don't recall seeing this bug, also using Ghostty, but v 1.1.3.

[nokernel]

@curtisbelt im on plain zsh 5.9 not using oh my zsh.

Terminal is iterm2

[merc1031]

I have been hitting this as well.

One data point, I don't have direct evidence, but i feel like it happens more if I run commands on different terminals.
Like I feel like i just triggered this by running some commands on one of my wezterm windows, then i switch to a vscode integrated terminal, and ran one command, then i can back to my wezterm window, and ctrl+r selected the wrong command (happened to be the command i ran in the vscode integrated terminal). I dont have the time spent between the sequence above though.

zsh-5.9 using wezterm over ssh and vscode over ssh

self hosted atuin server

sync_frequency = "30s"

[sync]
records = true

atuin store rebuild history seemed to fix it. Will update if i notice anything else

{
  "atuin": {
    "version": "18.5.0",
    "sync": {
      "cloud": false,
      "records": true,
      "auto_sync": true,
      "last_sync": "2025-04-26 1:47:39.363793171 +00:00:00"
    },
    "sqlite_version": "3.46.0"
  },
  "shell": {
    "name": "zsh",
    "default": "zsh",
    "plugins": [
      "atuin"
    ],
    "preexec": "built-in"
  },
  "system": {
    "os": "Ubuntu",
    "arch": "x86_64",
    "version": "24.04",
    "disks": [
      {
        "name": "/dev/mapper/ubuntu--vg-ubuntu--lv",
        "filesystem": "ext4"
      },
      {
        "name": "/dev/nvme0n1p2",
        "filesystem": "ext4"
      },
      {
        "name": "/dev/nvme0n1p1",
        "filesystem": "vfat"
      }
    ]
  }
}

[curtisbelt]

@ellie Here's that output you asked for:

atuin init zsh

# shellcheck disable=SC2034,SC2153,SC2086,SC2155

# Above line is because shellcheck doesn't support zsh, per
# https://github.com/koalaman/shellcheck/wiki/SC1071, and the ignore: param in
# ludeeus/action-shellcheck only supports _directories_, not _files_. So
# instead, we manually add any error the shellcheck step finds in the file to
# the above line ...

# Source this in your ~/.zshrc
autoload -U add-zsh-hook

zmodload zsh/datetime 2>/dev/null

# If zsh-autosuggestions is installed, configure it to use Atuin's search. If
# you'd like to override this, then add your config after the $(atuin init zsh)
# in your .zshrc
_zsh_autosuggest_strategy_atuin() {
    suggestion=$(ATUIN_QUERY="$1" atuin search --cmd-only --limit 1 --search-mode prefix)
}

if [ -n "${ZSH_AUTOSUGGEST_STRATEGY:-}" ]; then
    ZSH_AUTOSUGGEST_STRATEGY=("atuin" "${ZSH_AUTOSUGGEST_STRATEGY[@]}")
else
    ZSH_AUTOSUGGEST_STRATEGY=("atuin")
fi

export ATUIN_SESSION=$(atuin uuid)
ATUIN_HISTORY_ID=""

_atuin_preexec() {
    local id
    id=$(atuin history start -- "$1")
    export ATUIN_HISTORY_ID="$id"
    __atuin_preexec_time=${EPOCHREALTIME-}
}

_atuin_precmd() {
    local EXIT="$?" __atuin_precmd_time=${EPOCHREALTIME-}

    [[ -z "${ATUIN_HISTORY_ID:-}" ]] && return

    local duration=""
    if [[ -n $__atuin_preexec_time && -n $__atuin_precmd_time ]]; then
        printf -v duration %.0f $(((__atuin_precmd_time - __atuin_preexec_time) * 1000000000))
    fi

    (ATUIN_LOG=error atuin history end --exit $EXIT ${duration:+--duration=$duration} -- $ATUIN_HISTORY_ID &) >/dev/null 2>&1
    export ATUIN_HISTORY_ID=""
}

_atuin_search() {
    emulate -L zsh
    zle -I

    # swap stderr and stdout, so that the tui stuff works
    # TODO: not this
    local output
    # shellcheck disable=SC2048
    output=$(ATUIN_SHELL_ZSH=t ATUIN_LOG=error ATUIN_QUERY=$BUFFER atuin search $* -i 3>&1 1>&2 2>&3)

    zle reset-prompt
    # re-enable bracketed paste
    # shellcheck disable=SC2154
    echo -n ${zle_bracketed_paste[1]} >/dev/tty

    if [[ -n $output ]]; then
        RBUFFER=""
        LBUFFER=$output

        if [[ $LBUFFER == __atuin_accept__:* ]]
        then
            LBUFFER=${LBUFFER#__atuin_accept__:}
            zle accept-line
        else
            zle .infer-next-history && zle .up-history
        fi
    fi
}
_atuin_search_vicmd() {
    _atuin_search --keymap-mode=vim-normal
}
_atuin_search_viins() {
    _atuin_search --keymap-mode=vim-insert
}

_atuin_up_search() {
    # Only trigger if the buffer is a single line
    if [[ ! $BUFFER == *$'\n'* ]]; then
        _atuin_search --shell-up-key-binding "$@"
    else
        zle up-line
    fi
}
_atuin_up_search_vicmd() {
    _atuin_up_search --keymap-mode=vim-normal
}
_atuin_up_search_viins() {
    _atuin_up_search --keymap-mode=vim-insert
}

add-zsh-hook preexec _atuin_preexec
add-zsh-hook precmd _atuin_precmd

zle -N atuin-search _atuin_search
zle -N atuin-search-vicmd _atuin_search_vicmd
zle -N atuin-search-viins _atuin_search_viins
zle -N atuin-up-search _atuin_up_search
zle -N atuin-up-search-vicmd _atuin_up_search_vicmd
zle -N atuin-up-search-viins _atuin_up_search_viins

# These are compatibility widget names for "atuin <= 17.2.1" users.
zle -N _atuin_search_widget _atuin_search
zle -N _atuin_up_search_widget _atuin_up_search

bindkey -M emacs '^r' atuin-search
bindkey -M viins '^r' atuin-search-viins
bindkey -M vicmd '/' atuin-search
bindkey -M emacs '^[[A' atuin-up-search
bindkey -M vicmd '^[[A' atuin-up-search-vicmd
bindkey -M viins '^[[A' atuin-up-search-viins
bindkey -M emacs '^[OA' atuin-up-search
bindkey -M vicmd '^[OA' atuin-up-search-vicmd
bindkey -M viins '^[OA' atuin-up-search-viins
bindkey -M vicmd 'k' atuin-up-search-vicmd

---

I'm wondering if something might have changed with omz recently

I think you may be right... I need to test more, but I downgraded omz to...

• Feb. 19th 2025 ohmyzsh/ohmyzsh@6e7ac05

and the bug still occurred, HOWEVER, I then I downgraded further back to...

• Jan 10th 2025 ohmyzsh/ohmyzsh@276e540

and I could NOT reproduce it anymore! (and I've gotten good at reproducing it within 1-2 minutes)

I will work on this more in the morning... I think the bug may be caused by something in-between that commit range! I'm hoping so 😎

[paidhi]

@ebartels @octylFractal @monyxie @nokernel Taking a shot in the dark here - what terminal is everyone using? I'm using ghostty 1.1.2

Kitty 0.41.1 on Fedora Linux

[monyxie]

@ebartels @octylFractal @monyxie @nokernel Taking a shot in the dark here - what terminal is everyone using? I'm using ghostty 1.1.2

I'm using Terminator 2.1.4 on KDE Plasma.
I'm still on atuin 18.5.0 without the patches, but I did an omz reload 3 days ago. It didn't help.

[monyxie]

I'm able to 100% replicate this:

atuin2704.webm

[curtisbelt]

@monyxie Really nice find... I'm also getting 100% reproduction with your steps.

Peek.2025-04-26.03-33.webm

@ellie I am sad to report that downgrading omz did not actually fix it, I ended up reproducing the error way back into omz commits from August 2024...I even disabled all omz plugins.

And zsh itself, the latest version is 5.9 which was released in 2022 - so it's not that.

This is so strange 😢 let me know if there's anything else I can do!

[monyxie]

I did some more testing.

• Downgrading omz back to a commit from 1 year ago - issue persists.
• Disabling omz altogether - issue goes away.
• Downgrading atuin to 18.3.0 - issue goes away.

I then ran a bisect and it pointed to this commit.
I was able to make the issue go away with this:

diff --git a/crates/atuin/src/shell/atuin.zsh b/crates/atuin/src/shell/atuin.zsh
index 63b20b47..e75e7559 100644
--- a/crates/atuin/src/shell/atuin.zsh
+++ b/crates/atuin/src/shell/atuin.zsh
@@ -71,8 +71,8 @@ _atuin_search() {
         then
             LBUFFER=${LBUFFER#__atuin_accept__:}
             zle accept-line
-        else
-            zle .infer-next-history && zle .up-history
         fi
     fi
 }

[curtisbelt]

@monyxie

I'm unable to reproduce your fix. Can you let me know if I've done this correctly?

• Created a fork and branch zsh-select-bug from the latest main branch.
• Deleted those two lines as shown in your patch, and pushed commit here: main...curtisbelt-forks:atuin:zsh-select-bug
• Installed via: cargo install --git https://github.com/curtisbelt-forks/atuin --branch zsh-select-bug
• Shutdown all terminals, then started up 2 terminals.
• Performed the echo 1 2 3 4 dance, and still reproduced the bug 😢

I am on the latest omz version: omz version = master (959b6cf5).

[monyxie]

@curtisbelt Can you run this command and try to reproduce the bug again?

cargo install --git https://github.com/curtisbelt-forks/atuin --branch zsh-select-bug atuin --force

Also, just to make sure the atuin binary installed via cargo is in fact the one being used, can you post the output of which atuin?

[curtisbelt]

@monyxie

cargo install --git https://github.com/curtisbelt-forks/atuin --branch zsh-select-bug atuin --force

Restarted terminal. Could still reproduce the bug.

Then I ran which atuin... output is ~/.atuin/bin/atuin. (What should it be?)

---

Okay it turns out my atuin has never actually changed from v18.5.0
I found this command gives us the exact hash to confirm by:

atuin status
Atuin v18.5.0 - Build rev 53acf850f37d8cc8ffdcfebd7a73343f8dc339b6
[...]

That hash is the tagged v18.5.0 commit in atuin repo... ok, going to look into why my binary isn't changing. I'm pretty sure I originally installed atuin using the recommended command curl --proto '=https' --tlsv1.2 -LsSf https://setup.atuin.sh | sh

[monyxie]

The cargo command should show you the path to the atuin binary near the end of its output.

    ...
    Finished `release` profile [optimized] target(s) in 1m 48s
   Replacing /home/monyxie/.local/share/cargo/bin/atuin
    Replaced package `atuin v18.5.0 (file:///home/monyxie/code/atuin#1706c1d8)` with `atuin v18.5.0 (file:///home/monyxie/code/atuin#1706c1d8)` (executable `atuin`)

You need to make sure that directory is in your PATH and precedes ~/.atuin/bin/.

[curtisbelt]

@monyxie I got it fixed! I can no longer reproduce the bug! 🥳

cargo install \
  --git https://github.com/curtisbelt-forks/atuin.git \
  --branch zsh-select-bug \
  --root ~/.atuin \
  --force

Adding the --root ~/.atuin to the install command worked.

atuin status
Atuin v18.5.0 - Build rev bead125743546236d72083e95450de10b1c470e5

That's the correct hash from my fork 👍🏻

@ellie Apologies for not realizing my binary wasn't actually changed all this time! Looks like @monyxie and I are both confirmed cases of solving this bug with this very small patch: main...curtisbelt-forks:atuin:zsh-select-bug (credit to @monyxie for figuring that out).