I was able to give Guest root access lol . So what do I have to edit and to what to fix my sudoer powers for my arthur account, help appreciated as this Ive not done before.
Edit: I added myself to wheel group. This seemed to fix my super-powers.
usermod -aG wheel arthur
Even pamac works now. Hope this helps.
Uhm, meanwhile I received the 1.9.9 update and tried to see if that had anything to do with this...
now I got the error too, but there's no .pacnew ?
Off I go, reading Releases · sudo-project/sudo · GitHub .
sudo -nv is slow and counts as a failed login · Issue #131 · sudo-project/sudo · GitHub
Running a terminal/shell without starship allows to use sudo.
Sounds like a bug in starship… 
Hi, I was able to get rid of the message by adding the command_timeout= 3000 option to the ~/.config/starship.toml file:
## FIRST LINE/ROW: Info & Status
# First param ─┌
command_timeout = 3000
[username]
format = " [$user]($style)@"
...
Just got this bug too after updating the system. Tried resetting the config but that didn't help. Trying to work out if this is or should be fixed easily by us or if it's a bug and will be fixed in an update soon
I can use sudo without a problem btw. Just the warning about timing out at the top happens.
I though I managed to work around it with Defaults command_timeout = 1000 in /etc/sudoers but my joy only lasted that much, I opened another terminal and back to SNAFU.
I ended up downgrading sudo from bash (to avoid the starship problem) with
sudo pacman -U https://archive.archlinux.org/packages/s/sudo/sudo-1.9.8.p2-3-x86_64.pkg.tar.zst
but I don't know if that is the better option (though it's hinted at in the github issue linked above).
Doing so entails a "partial upgrade" situation, and manually merging the .pacnew in case /etc/sudoers was modified like I did -- though it seems to be working even with the config from 1.9.9 
<= edit: this seems to be wrong
## FIRST LINE/ROW: Info & Status
# First param ─┌
[username]
format = " [╭─$user]($style)@"
style_user = "bold cyan"
style_root = "bold cyan"
show_always = true
Do "#command_timeout = 3000"
It work fine here on KDE and i3wm 
Is it better I re-update sudo after applying this fix, or do I wait for the next one since I downgraded it?
Just try, I update every day, two - three times and have no problems with sudo.
Maybe use garuda-update to refresh fix everything.
I also use to update a few times a day, it makes me nervous when there are too many at once -- by the end of last year I left it alone for some days and it passed a hundred packages 
I'll set the command_timeout and update back to 1.9.9 then 
There happened some changes in sudo which cause this behaviour in combination with starships sudo element. No idea what exactly, but that's my conclusion
Fixing it could be done by disabling the sudo module in -/.config/starship.toml I guess. And this should be reported at the sudo repo as well 
(edit: it was already reported as linked below)
Update: it sort of works for me but not that much.
Note that I have an old machine, it’s usually responsive but slow nonetheless.
Prompts with starship take ~2 seconds with system idle, and I still run into problems under load.
This seems consistent with issue #131:
sudo -nv 0.00s user 0.01s system 0% cpu 1.937 total
In my case:
$ time sudo -nv
sudo: a password is required
real 0m2,549s <== waddafuq
user 0m0,009s
sys 0m0,009s
Increasing the timeout some more would probably work, but I cannot stand the delay.
I removed the command_timeout and disabled the starship sudo module as advised above by @dr460nf1r3 – instant gratification, no more delay nor problems.
Patiently waiting for sudo and starship to recover.
This is an excellent find! That’s the explanation I was missing, now it kinda makes sense 
I just noticed that files under /etc/sudoers.d/ use (ALL) not (ALL:ALL).
No idea whether they should.
Re my original post,
I did usermod -aG wheel arthur
and got my sudo working and this with Sudo version 1.9.9
Everything is all ok now.
I recall this happened before back in my ubuntu days. Half a day later I remembered lol.
Uhm, at first I was wary of security implications, now I noticed I'm already in the wheel group? Boh.