My wizard look like this:

Sorry, but I can't reproduce this.
Could you quickly try to run the wizard in another shell (bash or zsh without customizations)?
bash without custom font, does not look better...

Also, when I try to select something via cursor keys the wizard immediately fails with
Error: failed to run onboarding wizard: user aborted
Character encoding is set to UTF-8
Found something .... my default setting is
echo $TERM
xterm-256color
when I set it to
export TERM=linux
the interactive part looks fine.
[update]
works even better with TERM=xterm-color
Same as schmunk42 here: broken with (default) xterm-256color, ok with xterm-color.
The problem is most probably in one of the TUI libraries gopass is using (gocui, termbox-go).
I wonder if we can work around this by setting TERM=xterm-color on startup.
What works for me also, is:
alias gopass='TERM=xterm-color gopass'
in .bashrc.
After a recent Arch update (unsure which package), mine now looks like this too w/ pretty much stock bash. I can confirm setting the TERM variable did fix it.
I was bitten by the Arch rolling updates too. Workaround from @schmunk42 works perfectly though. Before stumbling across this issue, I did tinker with a few other terminal emulators and found a couple that weren't affected: terminology (presumably because it is EFL-based rather than xterm-based) and rxvt-unicode.
Yes. I've seen this before too.
But now it seems like it is resolved. At least for me.
Hmm, would be nice to a get a confirmation for the others affected by this, since I was never able to reproduce it.
@dominikschulz Unfortunately I'm working on a Mac today and so can't replicate but I've set a reminder to check when I'm on my Arch Linux box again tomorrow - I'll remove the workaround and see what happens.
@dominikschulz I can confirm that it's still producing the original problem - gopass 1.6.11.
And just to reiterate: if I leave TERM as default (i.e. xterm-256color) in my shell I get the problem. If I set TERM to xterm-color when starting gopass the problem goes away.
In #789 we updated the terminal libs, so this might be fixed.
I'm closing this for now. Just raise another issue if this comes up again.
The bug is fixed for me now, thank you.
Most helpful comment
What works for me also, is:
in
.bashrc.