Give Each VPN Account Its Own NetworkManager Launcher

Two VPN accounts, one gateway, and a desktop icon that connects as whoever used it last. The usual cause is a launcher that rewrites a shared profile's username just before connecting, or one that looks up a display name both profiles happen to share. NetworkManager already distinguishes profiles by UUID, so the icon can name exactly one of them and leave the identity alone. What it should not carry is the password.

A launcher is a pointer, not a credential store.

Find the UUID and confirm the identity

List the saved connections and read the UUID, the connection ID, and the username each profile stores. Confirm which profile belongs to which account before creating anything, because a display name is a label rather than a key. If the two accounts need different gateways or different profiles, that is a separate configuration task.

Use the UUID in the launcher. A display-name lookup works until somebody renames a profile, and then the icon connects as the wrong account or as nothing at all.

Write the desktop entry

A desktop entry needs a type, a name, and an executable line. The command should bring up that UUID and let NetworkManager ask for the secret, which is what nmcli --ask connection up uuid ... is for. Keep Terminal=true so the prompt is visible when a secret is needed. Replace the placeholder with the UUID you actually observed, and do not add a shell wrapper just to hide the prompt.

The Desktop Entry specification defines Exec as the program and its arguments. It is not a shell script, and it does not need one.

Let the agent hold the secret

Secrets belong to the per-user agent, the keyring, or an interactive prompt. A password in Exec is visible in the process list, in the desktop file, and in any screenshot of the properties dialog. If the profile needs a secret, let the supported prompt collect it and let the agent remember it for that user.

--ask is interactive by design. It is not a recipe for unattended automation, and it does not guarantee that every authentication challenge or plugin can be scripted at all.

Do not reach for sudo

Authorization to modify or activate a connection is a NetworkManager permission granted through its policy, not a Unix privilege. Running the launcher with sudo does not give the process another user's keyring, and it does not fix a gateway rejection. On a shared machine, review which local accounts can see which profiles and who owns each secret; separate icons do not create isolation by themselves.

Two active profiles for the same gateway can also compete over routes or violate a concurrency rule. That is a policy question rather than a launcher bug.

Verify the whole action

Activate the launcher once and confirm three things: the UUID that came up, the identity the gateway saw, and whether a secret prompt appeared where you expected. If the connection fails, keep the first error message. Adding the password to the command line to make the shortcut look self-contained hides that error and creates a worse problem.

Write the UUID and the account mapping into the team notes. The next person to change a profile needs to know which icon depends on it, and that note is what keeps a rename from becoming an outage.