You are not logged in.

#1 2026-07-17 08:57:39

kholo
Member
Registered: 2011-05-16
Posts: 5

Discord autostart with a wrong path after each update

Hello,

I encounter the same issue for a while now, after every package update, using the regular discord package from the extra repository.
I'm using KDE, and the application has autostart enabled, creating an entry in the Autostart section from the System Settings, but I don't think this is related to KDE as it's a .desktop file created in the $HOME/.config/autostart directory.
After each update, the Exec path is set to something like $HOME/.config/discord/app-X.X.XXX/Discord, X.XX.XXX being the previous version, not the newly installed, making Discord not to run at session start.
I always set it back to /usr/bin/discord but I don't understand this behavior.

Does anyone run into the same issue?

Offline

#2 2026-07-17 13:17:09

seth
Member
From: Won't reply 2 private help req
Registered: 2012-09-03
Posts: 77,885

Re: Discord autostart with a wrong path after each update

but I don't think this is related to KDE as

… session re/storage is disabled?
Does this happen if you explicitly close discord before logging out / shutting down?

Why is the executable stored in ~/.config/discord/app*/Discord at all?
https://archlinux.org/packages/extra/x86_64/discord/ ships usr/bin/discord and usr/share/applications/discord.desktop - symlinking the latter into https://wiki.archlinux.org/title/XDG_Autostart should™ autostart discord and if discord has some internal option to fudge autostarting, just disable that.

Offline

#3 2026-07-17 20:40:45

kholo
Member
Registered: 2011-05-16
Posts: 5

Re: Discord autostart with a wrong path after each update

seth wrote:

Why is the executable stored in ~/.config/discord/app*/Discord at all?

This I don't understand. I only installed the discord from Archlinux repository. Could it be an in-app update that would have fired and set itself as the new default Discord?

seth wrote:

if discord has some internal option to fudge autostarting, just disable that

Indeed when I toggle the autostart option from within Discord (being run from /usr/bin), it creates a desktop entry in the .config/autostart, where the ExecBin targets the .config/discord/app-X.XX.XXX/Discord file.
I untoggled the option and created manually the symlink to the package desktop entry, then when restarting Discord, it considers the option being toggled on again. Won't it overwrite the autostart entry during next update (using pacman/wrapper)? I'll wait and see.

If it does, I'll remove the package and the whole .config/discord directory, I'll reinstall it and see if the behavior differs.

I was just wondering if anyone encountered the same behavior, and if anyone did, if they know what fires it.

Offline

#4 2026-09-19 21:54:11

imusindacomputermom
Member
Registered: 2026-09-19
Posts: 1

Re: Discord autostart with a wrong path after each update

Hello! I made an account just to say this(sorry this isn't strictly about Arch) but this issue seems to also affect Fedora 44 KDE.

When enabling autostart inside of Discord settings it points to ~/.config/discord/app-*/Discord as-well.
Updating Discord doesn't update autostart, same with closing and re-opening discord after the update.

The only way I got discord to update autostart is to disable and re-enable it inside of Discord settings.

I had to do the same solution where I disabled autostart inside of Discord then re-add Discord to autostart through the KDE UI which points to /usr/bin/discord.

Last edited by imusindacomputermom (2026-09-19 21:58:26)

Offline

#5 Yesterday 00:03:56

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 25,388

Re: Discord autostart with a wrong path after each update

For generally clarification, the discord package is (recently) similar to steam, where the package installs a small shim that does the actual payload loading/updating into the home path which is likely where this discrepancy is coming from from "discord's POV". I'd assume ignoring the discord setting and simply maintaining that symlink to the system wide executable will likely properly bypass this.

Offline

Board footer

Powered by FluxBB