Why does GNOME Shell 49 on Ubuntu 25.10 ignore every new .desktop file I add, even after reinstalling gnome-shell and creating a brand new user?
https://askubuntu.com/questions/1566542/why-does-gnome-shell-49-on-ubuntu-25-10-ignore-every-new-desktop-file-i-add-ev
I'm hitting a wall with what seems to be a deep GNOME indexing issue and would really appreciate any insight from people who have seen something similar. I've been at this for many hours with no luck, and I've ruled out pretty much every standard hypothesis.
The problem
Any .desktop file I add to ~/.local/share/applications/ does not appear in the GNOME application overview when I press the Super key. Same thing happens for .desktop files added with sudo to /usr/share/applications/. Only applications that were already indexed before this issue started, plus Snap and Flatpak apps, are visible. New ones are completely ignored, regardless of where I put them.
This is not a "they appear with wrong icon" or "they're hidden in a folder" situation. They're simply not in the index at all. gtk-launch Nmap returns "no such application", gio launch ~/.local/share/applications/Nmap.desktop returns "Unable to load application information".
My setup
Ubuntu 25.10 (Questing)
GNOME Shell 49.0
Kernel 6.17.0-23
Wayland session
Indexer is localsearch (Ubuntu 25.10 replaced tracker3 with this)
Hardware: Ryzen 9 9950X, RTX 5080, ASUS ROG STRIX B650E-E
Example .desktop file
This passes desktop-file-validate cleanly (only an informational hint about the Security category, no errors):
[Desktop Entry]
Version=1.0
Type=Application
Name=Nmap
GenericName=Network Scanner
Comment=Network exploration tool and security scanner
Exec=gnome-terminal -- bash -c "/usr/bin/nmap -h; exec bash"
Icon=/home/stronk/Imagens/Icones/nmap.jpeg
Terminal=false
Categories=Network;Security;
Keywords=network;scanner;security;
StartupNotify=false
file says it's pure ASCII with LF line endings, no BOM. xdg-mime query filetype correctly identifies it as application/x-desktop. gio info confirms metadata::trusted: true. Permission is -rwxr-xr-x.
Things I have already tried (none made any difference)
File-level:
Validated syntax with desktop-file-validate (clean).
Checked encoding/line-endings (LF, ASCII, no BOM).
Set chmod +x.
Set GIO metadata::trusted true.
Pasta with 755 permission.
Added every optional Desktop Entry field I could think of (Version, GenericName, Comment, Keywords, StartupNotify).
Environment:
XDG_DATA_HOME was empty in the session. Added XDG_DATA_HOME=/home/stronk/.local/share to /etc/environment. Verified that gnome-shell itself now has the variable set, by reading /proc/$(pidof gnome-shell)/environ. No effect.
~/.config/mimeapps.list had application/x-desktop=org.gnome.TextEditor.desktop (which made .desktop files open in the text editor when double-clicked). Removed it. No effect on the indexing issue.
Caches and resets:
update-desktop-database runs successfully both on user and system folders. mimeinfo.cache updates with the right timestamp.
Full reboot: no change.
TimeShift restoration to three different snapshots from earlier in the day: no change.
Renamed ~/.local/share/gnome-shell/ to force regeneration: no change.
Cleared ~/.cache/gnome-shell/: no change.
Disabled all GNOME extensions (tilingshell, blur-my-shell, just-perfection-desktop, ding, snapd-prompting, tiling-assistant, ubuntu-appindicators, ubuntu-dock): no change.
dconf reset -f /org/gnome/desktop/app-folders/: no change.
Removed an empty ~/.config/menus/applications-merged/xdg-desktop-menu-dummy.menu (oddly owned by docker group, probably side effect of installing BloodHound via Docker): no change.
sudo apt install --reinstall gnome-shell gnome-shell-common: no change.
Cross-user verification (this is what makes me think it's a system bug):
Created a brand new user via sudo adduser teste and logged into their fresh session through GDM. Same exact issue. The new user also can't see the system-wide .desktop files I added to /usr/share/applications/. This rules out anything in /home/stronk/.
Suspicious things I see in logs
When I press Super and type a query, journalctl --user -f shows the shell activating various search providers via DBus:
Activating service name='org.gnome.Settings.SearchProvider'
Activating service name='org.gnome.Nautilus'
Activating service name='org.gnome.Calculator.SearchProvider'
Activating service name='org.gnome.Characters'
Activating service name='org.gnome.clocks'
Activating service name='org.gnome.seahorse.Application' [11+ recurrent calls in a tight loop]
There is nothing about AppSystem or AppDisplay in the logs when I search. The shell seems to query only registered search providers via DBus, never consulting the local app index for new entries.
There's also a recurrent warning that I find odd:
gnome-shell: Ignoring search provider /usr/share/gnome-shell/search-providers/seahorse-search-provider.ini: missing DesktopId
This warning is wrong. The .ini file does have DesktopId=org.gnome.seahorse.Application.desktop, the seahorse package is installed (47.0.1-2), and the corresponding .desktop file exists in /usr/share/applications/. Even after disabling that search provider entirely (by renaming the .ini to .disabled), the application indexing issue did not change.
Another anomaly: every login, three of my extensions get silently disabled by the shell — tilingshell, blur-my-shell, just-perfection-desktop. They show up disabled in gnome-extensions list --enabled even though I enabled them in the previous session. This suggests the extension subsystem is unstable, but the indexing issue persists even with all extensions disabled.
My current hypothesis
The AppSystem/AppDisplay subsystem of GNOME Shell 49 on Ubuntu 25.10 is broken in some way that:
Survives reboot.
Survives TimeShift restoration (TimeShift excludes /home by default, so user state isn't reverted, but system files are — and the issue persisted).
Survives gnome-shell package reinstall.
Affects a freshly created user account on the same machine.
This points to corruption either in the GNOME 49 packages shipped with Ubuntu 25.10, in some shared system state (/var/, mutter caches, glib state), or in a dependency of gnome-shell beyond gnome-shell-common.
Questions for the community
Has anyone seen this on Ubuntu 25.10 (Questing) or any GNOME 49 setup? Is there a known regression?
Is there a known location, beyond ~/.local/share/gnome-shell/ and ~/.cache/gnome-shell/, where shell-level app cache could persist?
Are there other packages I should reinstall along with gnome-shell and gnome-shell-common? I was thinking mutter, gnome-session, ubuntu-session, gnome-shell-extension-prefs, but wanted to ask before pulling the trigger.
Is there a way to ask the running gnome-shell to fully drop and rebuild its app index without a full system rebuild?
Could this be related to the new localsearch (replacing tracker3 in Ubuntu 25.10)? Has it changed anything in how the shell discovers apps?
Any pointer is welcome. I'd rather not reinstall the OS, but I'm running out of ideas. Thanks in advance.