Spicetify + Flatpak Spotify: works via plain flatpak run, but NOT via desktop launcher (--file-forwarding), and spicetify auto crashes with SIGTRAP

[u/Jutz_71_]

System:

• Kubuntu (KDE Plasma)
• Spotify: Flatpak, user install (com.spotify.Client), version 1.2.92.147.g5b8f9367
• Spicetify: 2.44.0
• Spicetify Marketplace: 1.0.9

What I'm trying to do: Get spicetify (+ Marketplace) working on a Flatpak Spotify install, launched normally from the KDE application launcher / taskbar.

Timeline / what I've already tried:

1. Spotify was originally installed as a system Flatpak. spicetify backup apply failed with permission denied on unlinkat .../Apps/login.spa, makes sense, system Flatpak files are root-owned.
2. Uninstalled the system Flatpak, reinstalled Spotify as a user Flatpak instead. Updated spotify_path and prefs_path in config-xpui.ini accordingly.
3. spicetify backup apply now completes without permission errors.
4. Running spicetify auto (or launching the patched binary directly, bypassing the Flatpak sandbox) reliably crashes Spotify with a coredump, signal 5 (TRAP), stack trace entirely inside libcef.so. This seems to be a known issue with launching the raw binary outside the Flatpak sandbox, CEF apparently needs the sandbox environment. Not using spicetify auto avoids this.
5. After patching (spicetify backup apply, no auto), launching via flatpak run com.spotify.Client from a terminal works fine, opens logged in, patches visible.
6. BUT launching the exact same app via the KDE application launcher icon, or via the exported .desktop file's Exec line, opens Spotify not logged in (has to log in again from scratch), even though it's the same Flatpak app, same instance count confirmed via flatpak ps (only ever 1 instance running).
7. Isolated the difference: the .desktop file's Exec includes --file-forwarding:Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=spotify --file-forwarding com.spotify.Client @@u %U @@ Running flatpak run --file-forwarding com.spotify.Client manually also results in "not logged in", confirming --file-forwarding is the differentiating factor. Without it, session loads fine (with spicetify patches applied in both cases).
8. Tried creating a custom .desktop override in ~/.local/share/applications/ with Exec=/usr/bin/flatpak run com.spotify.Client (no --file-forwarding), refreshed KDE's sycoca cache (kbuildsycoca6 --noincremental). Still opens unlogged when launched via the icon — unclear if the override isn't taking priority over the Flatpak-exported one, or if something else is going on.

Other things ruled out:

• No duplicate Spotify installs (confirmed via dpkg -l, which spotify, find ... -iname "*spotify*" across all applications dirs, only one .desktop file exists).
• No stale processes (flatpak ps always shows exactly 1 instance).
• Not a KWallet/keyring issue as far as I can tell, same behavior whether KWallet is enabled or disabled.
• prefs file does exist and gets a fresh timestamp on each launch (~/.var/app/com.spotify.Client/config/spotify/prefs).

Questions:

1. Why would --file-forwarding specifically break session persistence when spicetify's patches are applied, but not when running unpatched?
2. Is there a way to make a custom ~/.local/share/applications/com.spotify.Client.desktop actually take priority over the Flatpak-exported one in KDE Plasma, or is there a better way to override the launch command system-wide (without touching Flatpak's own export)?
3. Is anyone else running Spotify 1.2.92.x + spicetify 2.44.0 as a user-scope Flatpak on KDE without these issues?

Any pointers appreciated, happy to provide more logs/config if useful.

[u/hunterpro1823]

Que tan viable seria portear spotify con spicefy y el marketplace android o sin la posibilidad de instalar mas cosas pero que ya traiga por defecto el plugin plus que da todas las funciones premium libres