How to Fix Linux Menu Icons for Portable Electron Apps

You downloaded a Linux app as a portable folder or a raw binary — Antigravity IDE, a portable VS Code, a side-loaded Electron tool. You wrote a .desktop file, dropped it in ~/.local/share/applications/, and the app is gone from the menu. The launcher grid shows nothing. The search box finds nothing. You open the .desktop file and the Icon= line points at a perfectly valid PNG, yet the system acts like the icon does not exist.

The problem is almost never the icon file. The problem is whitespace in the path.

GNOME, KDE, and most freedesktop-compliant desktop environments parse .desktop files with a config parser that is unusually strict about spaces. A path like /home/ubuntu/Downloads/Antigravity IDE/resources/app/resources/linux/code.png will silently fail to load for two reasons: the unquoted space inside Icon= breaks the parser, and even when the parser survives, the desktop file validator (which runs when update-desktop-database regenerates the cache) treats the entry as malformed and drops it.

I burned an hour on this the first time. The second time I wrote the fix down. This is the four-step version that survives every Electron portable app I have thrown at it.

Step 1: Move the icon into a system folder with a clean path

Putting the icon in a folder that has a space in its name (such as /Downloads/Antigravity IDE/) is the most common way to get the loader to fail. The fix is to copy the icon file into your local icon directory, which always has a clean, space-free path.

Open a terminal and run:

cp "/home/ubuntu/Downloads/Antigravity IDE/resources/app/resources/linux/code.png" ~/.local/share/icons/antigravity-ide.png

Adjust the source path and the target filename to match your app. The ~/.local/share/icons/ directory is the XDG-compliant user icon path — every freedesktop environment scans it, and the path has no spaces or special characters that would trip up the parser.

Step 2: Write the .desktop file

Next, create a launcher entry so the app shows up in the system menu.

Open the file in your editor of choice:

nano ~/.local/share/applications/antigravity-ide.desktop

Paste the following configuration:

[Desktop Entry]
Name=Antigravity IDE
Comment=Antigravity IDE Launcher
Exec="/home/ubuntu/Downloads/Antigravity IDE/antigravity-ide" --no-sandbox
Icon=/home/ubuntu/.local/share/icons/antigravity-ide.png
Type=Application
Categories=Development;IDE;
Terminal=false

> Important: Wrap the Exec= path in double quotes ("...") if it contains spaces. For the Icon= line, point it at the clean-path file you copied in Step 1. The desktop file spec treats Icon= as a path, not a shell command, so do not quote it.

Save the file with Ctrl + O, then Enter. Exit the editor with Ctrl + X.

Step 3: Make it executable and refresh the cache

Two commands, in order:

chmod +x ~/.local/share/applications/antigravity-ide.desktop
update-desktop-database ~/.local/share/applications/

The first command sets the executable bit so the launcher can be invoked. The second regenerates the desktop file cache that GNOME and KDE read when populating the application grid. If you skip the second command, the launcher exists on disk but the menu will not see it until you log out and back in.

Step 4: Verify it worked

Open the application grid (or press the Super key and start typing the app name). The launcher should appear with the icon from ~/.local/share/icons/ instead of a generic placeholder. Click it. The app should launch.

If the icon still does not show, run desktop-file-validate ~/.local/share/applications/antigravity-ide.desktop — it will print the exact line that is malformed. Nine times out of ten, the failure is a missing quote on Exec= or a typo in the Icon= path.

Why this happens (and why the fix is permanent)

The underlying reason GNOME fails silently on unquoted paths is that the desktop entry spec uses a config-file format, not a shell script. When the parser sees Icon=/path/with spaces/file.png, it splits on whitespace and reads the second token as a key it does not understand, then drops the entry. The --no-sandbox flag on Exec= is unrelated to the icon issue but is required for most Electron apps to run as a non-Flatpak, non-Snap binary on modern Linux distributions.

The other thing worth knowing: .desktop files are case-sensitive, the keys (Name=, Exec=, Icon=, Type=, Categories=, Terminal=) are required, and Categories= must end with a semicolon. Drop the semicolon and the file still validates, but the menu will not categorize the entry correctly — it will end up in the “Other” bucket instead of “Development.”

The takeaway

The portable-Electron-icon-missing problem is not a GNOME bug. It is the desktop entry spec being unforgiving about paths. The fix is mechanical: copy the icon to ~/.local/share/icons/, quote Exec= if it has spaces, leave Icon= unquoted, run update-desktop-database, and the launcher works on every freedesktop-compliant environment — GNOME, KDE, XFCE, Cinnamon, MATE, LXQt, and the long tail of smaller ones.

It takes under a minute once you know the pattern. The first time it took me an hour of guessing and googling before I realized the spec was the source of truth, not the desktop environment.

If you have hit this with a specific app and the four steps above did not solve it, drop a comment with the app name, the desktop environment, and the output of desktop-file-validate — I will dig in.