背景

我使用的是arch linux + niri + dms（shorin niri）

为了方便下载和管理 IntelliJ IDEA 等开发工具，我安装了 JetBrains Toolbox，但是某天开机，我突然发现JetBrains Toolbox每次开机都会跟着启动，软件的图形化设置界面本找不到开机自启动的选项。

踩坑与摸索过程

1. 为什么设置里找不到开关？

经过一番排查，我发现这其实是 JetBrains Toolbox 环境检测机制的缺陷。它在启动时会去检测系统的 XDG_CURRENT_DESKTOP 环境变量，由于我用的是niri 环境，它未能识别出标准的桌面环境（如 GNOME 或 KDE），于是就把自启动的 UI 开关给隐藏了，但同时，它又通过 Linux 的 Freedesktop 标准，在后台偷偷写了自启动配置。

2. 修改 XDG 自启配置

既然它是通过 XDG 桌面规范来实现自启的，我就去检查了系统的自启目录 ~/.config/autostart/。果然，Toolbox 在这里生成了一个 .desktop 快捷方式。

我本想通过终端直接重定向写入一个覆盖文件来禁用它：

cat <<EOF > ~/.config/autostart/jetbrains-toolbox.desktop
[Desktop Entry]
...
Hidden=true
EOF

结果直接收获了一个无情的报错：fish: Expected a string, but found a redirection

我当前使用的 Fish Shell 为了交互体验，刻意放弃了对严格 POSIX 标准的完全兼容，不支持这种 HereDoc 的重定向语法 , 没办法，只能老老实实地打开了 micro 编辑器，手动创建并写入了这个配置文件。

3. Systemd 与 Generated 动态服务

可以使用 systemctl --user list-unit-files | grep autostart 命令来查看自启服务，然而发现这些服务的状态是 generated（动态生成）

原因是，在现代的 Arch Linux 中，systemd-xdg-autostart-generator 每次读取 ~/.config/autostart/ 目录里的 .desktop 文件，并临时把它们翻译成 systemd 服务

最终结论与通用解决方案

经历了这一番折腾，总结出了在 Arch Linux 中应对软件自启动的方案

当你发现一个软件悄悄自启时，请按以下逐一排查和处理：

  1. 排查软件自身的内部设置（首选）： 如果有图形化开关，直接关掉，让软件自己撤销写入的配置文件。

  2. 规范治理（针对遵守 XDG 规范的软件）： 就像这次的 Toolbox 一样，如果它偷偷在 ~/.config/autostart/ 目录写了文件，不要用目录去占位（这会产生系统日志报错），而是创建一个同名的 .desktop 文件，并在其中写入 Hidden=true。这会在标准规范层级明确告诉系统“拒绝自启”，同时防止软件发现文件丢失后再次流氓覆写。

  3. 系统级强杀（针对 Systemd 原生服务或极端软件）： 如果你遇到的是无视 Hidden=true 甚至疯狂修改配置文件的软件，可以直接用 Systemd 的Mask（屏蔽）， 执行 systemctl --user mask 软件服务名.service，这会在配置目录创建一个指向 /dev/null的软链接，无论软件怎么更新，Systemd 都会把它的启动请求直接忽略，彻底剥夺它的自启能力。

  4. 检查 WM/DE 底层脚本： 检查你的窗口管理器配置（例如 niri 的 config.kdl），看看是否包含了类似 spawn-at-startup 的启动指令。