Why a new VPN shortcut does not fix lost settings

Missing menu entries and vanishing preferences get fixed by the same reflex, and they are unrelated problems. One is desktop integration, the other is application state, and a new icon changes neither of them by itself. Separating the two takes one experiment and explains most of the confusion people bring to this topic. The launcher starts a program; the program decides what it remembers.

Two jobs that only look like one

Desktop integration means the environment can find an executable, present a name and an icon, and pass the right arguments. Application state means the program writes a profile somewhere durable and reads it back on the next start. Neither implies the other, which is why a working shortcut can launch a client that has forgotten everything.

Change one harmless display preference through the application's own controls, then close and reopen it the same way. If the preference returns, persistence works and the remaining complaint is about finding the window rather than saving data. If it disappears, the shortcut is a distraction and the real question is where that process keeps its files. Test one preference at a time, because a client that re-prompts for a password may be protecting a secret rather than losing a configuration.

Compare the launch inputs before reinstalling

Start at the desktop entry and read what it actually does, because a menu launch is not automatically the same process environment as a terminal launch. The keys that matter are Exec, Path and, indirectly, the environment the session provides. A wrapper script in Exec can set a variable, change directory or invoke a privileged helper the menu never shows. Reinstalling replaces files the application already had, which is rarely the variable that changed.

grep -h '^Exec=' ~/.local/share/applications/*.desktop
desktop-file-validate ~/.local/share/applications/client.desktop

Look at the file under ~/.local/share/applications before the one in /usr/share/applications, since a user copy shadows the system copy. Run desktop-file-validate when the entry misbehaves, and look for a stale copy that still points at a removed path. An invalid user copy is still preferred by most desktops, so a broken file can remove the entry from the menu while the package-owned file remains valid. Then run the same command by hand and compare what the two launches produce.

Where a preference actually lives

Applications that follow the XDG base directory rules put configuration under $XDG_CONFIG_HOME, durable state under $XDG_STATE_HOME and disposable data under $XDG_CACHE_HOME, defaulting to ~/.config, ~/.local/state and ~/.cache when those variables are unset. The three are roles rather than promises, so a particular VPN product may document something else entirely. Reading the vendor's own documentation beats guessing a path from a directory name. When the documentation is thin, watch the process instead of the filesystem.

A trace filtered to file opens shows every configuration path the client tries, including the one it writes at exit. Run it as the same user with the same environment, then compare those paths against the directories you expected.

strace -f -e trace=openat,stat -o /tmp/vpn.log vpn-client

Secrets and profiles have different owners

A saved profile and a saved credential are separate objects, often with separate storage. One may live in a configuration file while the other sits in a keyring that unlocks per session, so a client asking for a password again may simply be doing what it was designed to do. Deleting the profile to stop the prompt is how people lose a working configuration.

Privileged launches complicate this further, since a launch through sudo or a policy-kit helper can present a different home directory and therefore a different configuration set. Fix ownership on the specific file the application documents rather than recursively across a home directory, then decide which identity should own the profile going forward and keep future launches consistent with it.

What the icon can and cannot tell you

An icon proves that a launcher file resolves, and nothing more. Connection state belongs to the client, so the only reliable check is the interface, the route or the client's own status output. A tray applet that failed to start can make a working tunnel look broken, while a stale applet can make a broken one look fine. Test the connection and the launcher separately, then write down which one you actually fixed.

If both were broken, resist treating the repair as one change. Fix the entry, confirm the launch, then confirm the tunnel, and note the result of each step. That record is what makes the next report of lost settings diagnosable instead of a repeat of this one, and it is also what tells the next person which half of the problem was real.