Opening the same apps every morning can feel like teaching your computer a trick it should already know. You log in, launch your browser, open your notes app, start your VPN, wake up your chat client, and maybe start a terminal because, naturally, Linux users are contractually obligated to have at least one terminal nearby. Good news: GNOME Shell can do this for you.
This guide explains how to autostart programs on GNOME Shell using beginner-friendly graphical tools, manual .desktop files, and more advanced systemd --user services. Whether you use Ubuntu, Fedora, Debian, Arch, openSUSE, or another GNOME-based Linux desktop, the core idea is the same: tell your session what should launch after you log in.
The best method depends on what you want to start. A normal desktop app such as Slack, Firefox, Thunderbird, KeePassXC, or a cloud sync tool belongs in GNOME’s startup applications. A background service, script, daemon, or long-running command may be better handled with a user-level systemd service. Let’s walk through both without turning your login session into a haunted house of mystery processes.
What “Autostart” Means in GNOME Shell
In GNOME Shell, autostart usually means launching an application automatically after a user signs in to the graphical desktop. This is different from starting a system service during boot. A boot service can run before anyone logs in; a GNOME autostart program starts after your desktop session begins.
That distinction matters. A graphical app needs a desktop session, display server, user environment, and sometimes secrets from GNOME Keyring. Starting it too early can cause confusing failures. For example, a VPN app with a tray indicator, a clipboard manager, or a note-taking app should normally launch after GNOME is ready, not while the system is still booting.
The Easiest Way: Use GNOME Tweaks
For most users, GNOME Tweaks is the simplest way to autostart programs on GNOME Shell. It gives you a clean graphical interface where you can add installed applications to your startup list without hand-editing configuration files.
Install GNOME Tweaks
GNOME Tweaks may already be installed. If not, use the command for your distribution:
On Fedora:
On Arch Linux:
Add a Startup Application
- Open the Activities overview.
- Search for Tweaks.
- Open GNOME Tweaks.
- Go to Startup Applications.
- Click the + button.
- Select the application you want to launch automatically.
- Click Add.
That is the entire process. Log out and log back in to test it. If the app opens automatically, congratulations: your desktop has learned a new party trick.
Using Ubuntu’s Startup Applications Tool
On Ubuntu GNOME, you may also find a tool called Startup Applications or Startup Applications Preferences. You can open it from the Activities overview, or run:
This tool lets you add a name, command, and comment. It is useful when you want to autostart a command that does not appear neatly in GNOME Tweaks. For example, you could add a small script, a background helper, or an app with custom launch flags.
A typical entry might look like this:
When you log in, GNOME runs the command as your user. Keep it simple. If your command works in the terminal but fails at login, use full paths and check whether it depends on environment variables that are not available yet.
How GNOME Autostart Works Behind the Scenes
GNOME follows the XDG Autostart system used by many Linux desktop environments. Startup entries are usually stored as .desktop files in one of these locations:
The first path is for your user account. The second path is system-wide and affects all users. If you add a startup app through GNOME Tweaks, GNOME typically creates or copies a .desktop file into your personal ~/.config/autostart/ folder.
This is why GNOME autostart is surprisingly portable. The same basic format works across many Linux desktops. Under the friendly buttons and switches, it is mostly plain text files doing plain text file things. Linux loves a text file so much it would probably put birthday candles on one.
Manual Method: Create a .desktop Autostart File
If GNOME Tweaks does not show the program you want, create the autostart entry yourself. This is especially useful for custom scripts, AppImages, developer tools, or programs installed outside your package manager.
Create the Autostart Folder
Create a Desktop Entry
Now create a file such as:
Add this basic template:
Save the file, log out, and log back in. If the command is correct, GNOME should launch it automatically.
Important .desktop Fields
The Type=Application line tells the desktop that this entry launches a program. Name is the readable label. Exec is the actual command. Terminal=false means the app does not need a terminal window. If your script must run in a terminal, set it to true, although most background tasks should avoid opening a terminal at login.
The Exec line is the most important part. It can contain an executable name, such as firefox, or a full path, such as /usr/bin/firefox. For custom scripts, full paths are usually safer.
Autostart a Shell Script in GNOME
Suppose you have a script that sets up your workspace. First, create the script:
Example script:
Make it executable:
Then create an autostart file:
Add:
Replace yourname with your real Linux username. Do not use ~ in every situation and expect all desktop launchers to expand it perfectly. Full paths reduce drama, and Linux drama is best saved for printer drivers.
Add a Delay Before Launching an App
Some apps behave better if they start a few seconds after login. Cloud sync clients, VPN tools, network utilities, and Electron apps can occasionally trip over themselves if launched too early.
You can add a delay by wrapping the command in a shell:
Or put the delay inside a script:
The script approach is easier to read and troubleshoot. It also avoids quoting problems in .desktop files, which can become annoying when commands contain spaces, special characters, or arguments.
Autostart Flatpak Applications
Flatpak apps can also start automatically. If the app appears in GNOME Tweaks, add it there. If not, you can use its Flatpak application ID.
List installed Flatpak apps:
Then use a command like:
A matching autostart entry may look like this:
For real apps, replace com.example.AppName with the actual Flatpak ID. Many Flatpak desktop files also live under user or system application directories, so copying an existing launcher into ~/.config/autostart/ can work well.
Autostart AppImages
AppImages are portable Linux applications. To autostart one, store it in a stable location, make it executable, and point your .desktop file to it.
Example autostart file:
Avoid keeping the AppImage in your Downloads folder if you plan to autostart it. Downloads folders are where files go to be forgotten, renamed, duplicated, and eventually judged during a cleanup session.
Autostart Programs for All Users
If you manage a shared machine, classroom lab, office workstation, or family computer, you may want an application to start for every user. In that case, place the .desktop file in:
You need administrator privileges:
Use this carefully. A system-wide autostart entry affects everyone who logs in to GNOME. That is great for required agents, accessibility tools, update helpers, or organization-managed utilities. It is less great for launching your personal music player on every account. Nobody wants surprise jazz at login unless it is clearly documented company policy.
Disable or Remove Startup Applications
To remove a startup app from GNOME Tweaks, open Tweaks, go to Startup Applications, and remove the entry. If you created it manually, delete the corresponding file:
You can also disable an entry without deleting it by editing the file and setting:
Another common method is to add:
This tells the desktop environment not to run that autostart entry. It is especially useful when overriding a system-wide entry from /etc/xdg/autostart/ with a user-specific file of the same name.
When to Use systemd User Services Instead
GNOME autostart is best for graphical applications. But some tasks are better as systemd --user services. Use a user service when the program is a background daemon, needs restart behavior, produces logs, or should be managed like a service rather than a visible desktop app.
Good candidates include custom sync scripts, development helpers, background agents, local servers, automation tools, and long-running commands. Poor candidates include normal GUI apps that need the desktop to be fully ready.
Create a User Service
Create the user systemd directory:
Create a service file:
Example:
Reload systemd and enable the service:
Check its status:
View logs:
This approach is powerful, but do not use it blindly for GUI apps. A service may start without the right graphical environment unless it is designed carefully. For everyday desktop applications, GNOME’s autostart folder is usually the better fit.
Troubleshooting GNOME Autostart Problems
The App Does Not Start
First, test the command manually in a terminal. If the command fails there, GNOME cannot magically fix it. Check spelling, paths, permissions, and whether the app is installed.
The Script Is Not Executable
If you are launching a script, make it executable:
The Path Is Wrong
Use full paths in custom entries. Instead of:
Use:
The App Starts Too Early
Add a delay with sleep. This is common for network-dependent apps. A five- to ten-second delay can solve login race conditions without requiring a full detective board with red string.
The Command Needs Environment Variables
Autostart commands may not inherit the same shell setup as your interactive terminal. If your command depends on custom variables from .bashrc or .zshrc, define them inside the script or use absolute paths.
The .desktop File Has Syntax Issues
Desktop files are simple, but they are not chaos-friendly. Make sure the file starts with [Desktop Entry], includes Type=Application, and has a valid Exec line. The file should end in .desktop.
Best Practices for Startup Applications
Keep your startup list short. Autostart is convenient, but launching too many programs can slow your login and clutter your session. Start only what you actually use every day.
Prefer graphical autostart for graphical applications. Use user systemd services for background processes. Use scripts when you need multiple commands, delays, or setup logic. Use system-wide autostart only when every user truly needs the program.
Review your startup entries every few months. Old cloud clients, abandoned applets, duplicate launchers, and forgotten experiments can pile up. Your desktop should feel like a workspace, not a yard sale with a login screen.
Practical Examples
Start Firefox After Login
Start a VPN GUI
Start a Script With Delay
Start a Background Helper With systemd
Experience Notes: What I’ve Learned from Autostarting GNOME Programs
Autostart looks like a tiny convenience feature, but it can change how your Linux desktop feels every day. A well-planned GNOME startup setup makes the system feel polished, personal, and ready. A messy one makes login feel like opening a closet and having twelve apps fall on your head.
The first practical lesson is to start small. Add one or two essential applications, test them, and then add more only if needed. Many people get excited and add everything: browser, email, chat, terminal, music, password manager, cloud sync, calendar, weather app, clipboard manager, system monitor, and three tools they installed during a late-night “productivity upgrade.” The next login becomes slow, noisy, and confusing. Autostart should remove friction, not create a parade.
The second lesson is that timing matters. Some applications need the network, keyring, display environment, or extensions to be ready. If an app behaves inconsistently, add a short delay. A simple sleep 5 or sleep 10 inside a script can make the difference between a clean startup and an app that launches once, crashes politely, and leaves no helpful explanation.
The third lesson is to separate desktop apps from background jobs. GNOME autostart is excellent for programs you can see and use. For invisible helpers, systemd user services are cleaner. They provide status checks, restart rules, and logs. When something fails, journalctl --user is much more useful than staring at your desktop and whispering, “But it worked yesterday.”
The fourth lesson is to use full paths for personal scripts and unusual applications. Desktop launchers do not always behave exactly like your interactive terminal. Your shell may know where a command lives because of custom configuration, but GNOME’s session launcher may not. Full paths are boring, but boring is wonderful when troubleshooting.
The fifth lesson is to document your own setup. Add clear names and comments in your .desktop files. Store scripts in a sensible folder such as ~/bin or ~/Scripts. If you return months later, you should be able to understand what each entry does without needing archaeology tools and emotional support.
Finally, review your autostart list whenever your desktop starts feeling slow. Startup clutter often grows quietly. A tool you needed last semester, a test script from a project, or a duplicate entry from an app reinstall can keep launching long after it is useful. Clean it up, log out, log back in, and enjoy the rare luxury of a computer doing exactly what you asked and nothing more.
Conclusion
Learning how to autostart programs on GNOME Shell gives you more control over your Linux desktop and saves time every time you log in. For most users, GNOME Tweaks or Startup Applications Preferences is the fastest and safest option. For custom commands, scripts, Flatpaks, AppImages, and advanced workflows, manual .desktop files in ~/.config/autostart/ provide flexibility. For background services, systemd --user offers better management, logging, and reliability.
The golden rule is simple: use the right startup method for the job. Graphical apps belong in GNOME autostart. Background daemons often belong in user services. System-wide entries should be reserved for programs that every user truly needs. Keep your setup lean, test each command, and your GNOME session will open exactly the way you want itno repetitive clicking required.
