If you use KDE Plasma 5 every day, there are a few apps you probably want ready before your coffee finishes its first dramatic swirl. Maybe it is a clipboard manager, a chat app, a cloud sync tool, or a terminal that lives quietly in the background until you need it. Whatever the case, learning how to autostart programs on KDE Plasma 5 can make your desktop feel smoother, faster, and a lot more personal.
The good news is that Plasma 5 gives you more than one way to do it. You can use the friendly graphical settings panel, add a custom script, create a manual .desktop launcher, or even manage system-wide startup behavior when needed. The less-good news is that Linux startup behavior can get a little spicy when session restore, Flatpaks, custom scripts, and distro defaults all walk into the same room.
This guide breaks it all down in plain English. By the end, you will know the easiest way to autostart apps, when to use scripts instead of launchers, how to troubleshoot stubborn programs, and how to keep your Plasma session from launching two copies of the same app like it is auditioning for a buddy comedy.
What autostart means in KDE Plasma 5
Before clicking buttons, it helps to understand what “autostart” really means on Plasma 5. In desktop Linux, autostart usually means an application launches after you log in to your graphical desktop session, not necessarily when the whole computer boots up.
That distinction matters. If you want a background service to run before anyone logs in, Plasma autostart is usually not the right tool. For that kind of job, a system service or user service managed by systemd is often the better choice. Plasma autostart is ideal for things tied to your personal desktop session: chat clients, sync apps, tray tools, terminals, notes apps, and utility scripts.
In KDE Plasma 5, the built-in Autostart module lets you add three basic types of startup items:
- Applications
- Login scripts
- Logout scripts
That means you are not limited to just clicking an app from a list. You can also launch your own shell scripts, which is great when you need a little startup logic, a delay, or a workaround for an app that behaves like a diva before the network is fully awake.
The easiest method: use KDE Plasma 5 System Settings
If you want the cleanest, most beginner-friendly way to autostart programs on KDE Plasma 5, use the graphical control panel. Plasma 5 already includes a dedicated Autostart section, and for everyday apps it is usually the best option.
Step-by-step instructions
- Open System Settings.
- Go to Startup and Shutdown.
- Click Autostart.
- Choose Add Program or Add Application depending on your distro’s wording.
- Select the app you want to launch automatically when you log in.
- Apply the change and log out, then log back in to test it.
That is it. For many users, this solves the problem in under a minute. Apps such as KeePassXC, Discord, Telegram, Tilda, KDE Connect Indicator, or a sync client are perfect examples of good autostart candidates.
This method is especially nice because it keeps everything visible in one place. Later, if you decide an app no longer deserves startup VIP status, you can return to the same menu and disable or remove it without digging around your home folder like a digital archaeologist.
When this method works best
Use the System Settings method when:
- The program is already installed normally
- The app has a standard launcher entry
- You want a simple per-user startup rule
- You do not need custom command-line arguments
If that describes your situation, congratulations: you just found the low-stress route.
How to autostart a custom script on KDE Plasma 5
Sometimes an ordinary app launcher is not enough. Maybe you want to set a keyboard layout, start two commands in sequence, delay a noisy app for ten seconds, or export an environment variable before something opens. That is where scripts come in.
In the same Autostart section, KDE Plasma 5 lets you add a Login Script. This runs after you sign in to your Plasma session.
Example: create a login script
Create a file like ~/bin/start-my-tools.sh and make it executable:
Then run:
Now go back to System Settings > Startup and Shutdown > Autostart, choose Add Script or Add Login Script, and point Plasma to that file.
This is useful when an app starts too early, needs a delay, or depends on another part of your session already being available. It is also a clean way to group related startup actions into one place.
Use full paths in scripts
One of the most common startup mistakes is assuming the environment during login behaves exactly like your interactive terminal. It often does not. That is why it is smart to use full paths such as /usr/bin/konsole instead of just konsole, especially in scripts. It saves you from the classic “works in terminal, fails at login” mystery.
How to manually autostart apps with ~/.config/autostart
If you like doing things the Linux way, which often means “with a text file and a little swagger,” you can manually add a startup entry by using the standard autostart directory:
This is the standard per-user location for desktop autostart entries. If it does not exist yet, create it:
Then create a .desktop file inside that folder. For example:
Save that as:
After your next login, Plasma should launch it automatically.
Why this method is powerful
This approach gives you more control than the GUI. You can change the command, add arguments, point to a wrapper script, or version-control your startup setup if you are the sort of person who keeps dotfiles tidy and alphabetized. In other words, the kind of person Linux secretly hopes you become.
You can also copy an existing launcher from /usr/share/applications into your personal autostart folder, then edit it safely without changing the system-wide original.
Example: delayed launch from a desktop entry
If a program needs extra time before launching, you can point the Exec line to a shell command:
This trick is handy for apps that start before networking, tray services, or the Plasma panel are fully ready.
How to disable startup items you do not want
Autostart is not just about adding programs. Sometimes the smarter move is removing them. If your session feels heavy, delayed, or cluttered, trimming unnecessary startup apps can make KDE Plasma 5 feel much snappier.
You can disable items in the graphical Autostart panel, but you can also override system-wide startup entries. Plasma and other Linux desktops commonly use a system-wide autostart folder:
If your distribution installed a startup item there, you can override it for your own account by copying the matching .desktop file into your personal ~/.config/autostart folder and adding:
That tells the desktop to ignore the matching startup entry for your user account. It is a simple, standard way to say, “Thank you, but no thank you” to a startup item your distro thought you would love forever.
Autostart applications vs session restore
This is the part that confuses a lot of users. Sometimes an app opens on login even though you never added it to Autostart. Why? Because Plasma may be restoring the previous session.
In KDE Plasma 5, the Desktop Session settings can restore apps that were open when you logged out. If you also added one of those apps to Autostart, Plasma might launch it twice. That is not your imagination. That is startup duplication with extra confidence.
How to fix duplicate app launches
Check this setting:
- Open System Settings.
- Go to Startup and Shutdown.
- Open Desktop Session.
- Look at the On Login behavior.
If you want only your explicit startup apps to run, choose Start with an empty session. If you prefer Plasma to reopen what you had before logout, then avoid adding those same apps in Autostart unless you truly enjoy surprises.
Advanced Plasma 5 startup folders worth knowing
If you want finer control, Plasma also recognizes a few special folders related to startup behavior.
~/.config/autostartfor normal application launchers and login-time desktop entries~/.config/plasma-workspace/envfor scripts that run earlier in the startup process~/.config/plasma-workspace/shutdownfor scripts that run during logout
The env folder is useful for pre-startup scripting, especially when you need environment variables or early session customization. The shutdown folder is useful for cleanup tasks, though it is obviously not an autostart feature in the strict sense. Think of it as the polite goodbye half of the startup-and-shutdown relationship.
For most users, you will rarely need these folders manually because the GUI covers the common cases. Still, knowing they exist can save time when you move beyond standard app launching.
When to use systemd instead of Plasma autostart
Some programs should not be managed by the desktop at all. If a tool needs to run whether or not the Plasma session is open, or it should behave more like a persistent service than a desktop app, systemd is often the better fit.
Use a service instead of Plasma autostart when:
- You need background behavior not tied to the GUI
- The process should restart automatically if it crashes
- The task should start at boot or remain independent of Plasma
- You are managing long-running daemons or agents
Use Plasma autostart when the thing you are launching is really part of your desktop life. In plain terms: if it lives in your tray, pops a window, or exists mainly because you logged in, Plasma autostart is probably the right tool.
Troubleshooting: why your startup app is not launching
If your autostart entry refuses to cooperate, do not panic. Most issues come from a small handful of causes.
1. The command is wrong
Double-check the Exec command. Run it manually in a terminal first. If it fails there, it will not magically improve its attitude during login.
2. The script is not executable
For shell scripts, make sure you ran chmod +x your-script.sh.
3. The app needs a delay
Some apps start too early. Wrap them in a small shell script with sleep 5 or sleep 10 and autostart the wrapper instead.
4. The desktop entry uses the wrong environment
Use full executable paths and avoid relying on your interactive shell setup unless you know exactly how the login environment is prepared.
5. The program is blocked by desktop rules
Some .desktop files include keys such as OnlyShowIn, NotShowIn, or TryExec. Those can prevent an app from launching if the environment or executable does not match.
6. Session restore is confusing the result
If an app appears twice, or opens even after you removed it from Autostart, check your session restore settings.
Best practices for a clean KDE Plasma 5 autostart setup
To keep your startup smooth instead of chaotic, follow a few simple rules:
- Autostart only what you use daily
- Prefer the Plasma GUI for simple apps
- Use scripts for delays, multiple commands, or custom logic
- Keep manual
.desktopentries neat and clearly named - Review startup items every few months
- Avoid autostarting giant apps you open once a week
Your future self will thank you, especially on the day you log in and your desktop does not sound like it is preparing for launch at Mission Control.
Experience-based lessons from using KDE Plasma 5 autostart in real life
In real-world use, KDE Plasma 5 autostart is one of those features that seems tiny until you tune it properly. Then suddenly your desktop stops feeling like a generic Linux install and starts feeling like your machine. The biggest lesson most users learn is that fewer startup items usually lead to a better experience. It is tempting to autostart everything you use regularly, but that can backfire fast. A clipboard manager, password vault, cloud sync app, and maybe one communication tool make sense. Adding a browser, two chat apps, a music player, a notes app, and a heavy IDE just because “I might need them later” is how a fast login turns into a small ceremony.
Another practical lesson is that KDE’s graphical Autostart panel should usually be your first stop. It is simple, visible, and easy to reverse. For a lot of users, that is enough forever. Where things get more interesting is with stubborn apps. Some programs behave perfectly when launched by hand but get weird at login. They open too early, fail to find the network, or appear before the system tray is ready. That is when a tiny script with a short delay becomes incredibly useful. It feels a little old-school, but it works. In Linux, a five-line script can solve a problem that would otherwise waste an afternoon.
One especially common surprise is session restore. Many users think an app is in Autostart when Plasma is actually reopening the previous session. Then they add the same app to Autostart and accidentally create duplicates. That confusion is so common it practically deserves its own warning label. If your apps multiply after login, check session settings before blaming the launcher file.
There is also a good workflow lesson here: test one startup change at a time. Add one app, log out, log back in, and see what happens. If you add five startup items and one breaks, now you are playing detective in a room full of suspects. Small, deliberate changes make troubleshooting much easier.
For power users, the manual .desktop route is where Plasma 5 becomes really flexible. It lets you fine-tune commands, use wrapper scripts, and override distro defaults without touching system files. That makes the setup cleaner and safer. And once you understand the structure, it becomes easy to migrate your startup habits to another machine. Copy a few launchers, move a script or two, and your new Plasma desktop starts to feel familiar almost immediately.
The final lesson is philosophical, in the very nerdy Linux sense of the word. Startup should support your workflow, not show off how many clever tricks you know. The best autostart setup is usually the one you barely notice. You log in, the right tools are there, nothing launches twice, nothing slows the session down, and everything behaves like it got enough sleep. That is the real win with KDE Plasma 5 autostart: not more complexity, but less friction.
Final thoughts
If you want to autostart programs on KDE Plasma 5, the easiest route is the built-in System Settings > Startup and Shutdown > Autostart panel. It is fast, safe, and good enough for most users. When you need more control, use a script or create a manual .desktop file inside ~/.config/autostart. And if something seems haunted, check session restore before accusing Plasma of mischief.
Once you set it up correctly, autostart becomes one of those small desktop improvements that pays off every single day. Your favorite tools are ready, your session feels intentional, and you spend less time launching the same apps over and over. That is not just convenience. That is desktop quality of life.
