Why Proxy Settings Work in a Terminal but Not a Desktop Launcher

You export a proxy in a terminal. A command started there uses it. Clicking the desktop icon still gives another route. The icon did not become a child of that terminal.

A desktop session starts applications through its own launch machinery. Those processes inherit that environment, not every later edit made inside an unrelated shell. This can explain a difference without proving that the application package is defective.

Exec is a command description, not a shell script

The Desktop Entry specification defines an executable and arguments for Exec. It does not promise shell variable expansion or shell builtins.

For an external program that reads the relevant environment variable, a deliberately scoped launch can have this shape:

Exec=env https_proxy=http://proxy.example:8080 /path/to/application

Replace both the endpoint and executable. This demonstrates the launch input, not a guarantee that an arbitrary application reads that variable. A browser with its own explicit proxy policy can still choose another configuration source. For Chrome, save its proxy argument in a user launcher.

Do not write Exec=export ... and expect the desktop to interpret it as your login shell. Keep the desktop entry's quoting rules and supported field codes in view too; they are another parser.

Check whether anything new was launched

Some applications send the request to an instance already running. Some entries use D-Bus activation, which has its own launch path. A new icon click does not establish a fresh process with the newly edited Exec environment.

Identify the instance making the request and the configuration it actually owns. A controlled fresh launch can narrow the comparison when appropriate. Avoid reinstalling the application before establishing that the intended environment ever reached it.