在 Linux 桌面环境中，有些后台服务本身运行正常，却无法启动可见窗口。这个问题表面上像是浏览器坏了，或者应用自身没有正确识别图形环境；但实际原因往往更底层：服务启动时没有继承当前图形会话的环境变量。
这次遇到的问题是：OpenClaw Gateway 作为 systemd --user 用户服务运行，终端可以正常连接 Gateway，TUI 也能启动，但让它打开可见浏览器时失败，提示当前服务环境中没有 $DISPLAY 或 $WAYLAND_DISPLAY。
问题现象
在终端中启动 OpenClaw TUI 后，输入“打开浏览器”，返回类似提示：
无法打开可见浏览器：
OpenClaw 当前进程未检测到图形显示环境，
$DISPLAY 和 $WAYLAND_DISPLAY 均未设置。
但此时桌面环境本身是正常的，终端也处在 KDE 图形桌面中。也就是说，问题并不是“系统没有图形界面”，而是 OpenClaw Gateway 这个后台服务进程没有拿到图形会话环境。
初步确认：这是用户服务，不是系统服务
一开始容易犯的错误是直接查系统级服务：
systemctl status openclaw
systemctl status openclaw-gateway
结果会显示：
Unit openclaw-gateway.service could not be found.
这并不代表服务不存在，而是因为 OpenClaw Gateway 安装为用户级 systemd 服务，应使用：
systemctl --user status openclaw-gateway.service
用户级服务文件位于类似：
~/.config/systemd/user/openclaw-gateway.service
这类服务由当前用户的 systemd --user 管理，而不是系统级 systemd 管理。
检查当前终端环境与服务进程环境
问题的关键在于比较两层环境：
一层是当前终端环境：
echo "DISPLAY=$DISPLAY"
echo "XAUTHORITY=$XAUTHORITY"
echo "XDG_SESSION_TYPE=$XDG_SESSION_TYPE"
echo "XDG_CURRENT_DESKTOP=$XDG_CURRENT_DESKTOP"
echo "DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS"
echo "XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR"
在 KDE X11 会话中，终端里通常能看到类似：
DISPLAY=:0
XAUTHORITY=/tmp/xauth_xxxxxx
XDG_SESSION_TYPE=x11
XDG_CURRENT_DESKTOP=KDE
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_RUNTIME_DIR=/run/user/1000
另一层是 OpenClaw Gateway 实际运行进程的环境：
PID="$(systemctl --user show -p MainPID --value openclaw-gateway.service)"
echo "PID=$PID"
tr '\0' '\n' < "/proc/$PID/environ" \
| grep -E '^(DISPLAY|XAUTHORITY|WAYLAND_DISPLAY|XDG_SESSION_TYPE|XDG_CURRENT_DESKTOP|DBUS_SESSION_BUS_ADDRESS|XDG_RUNTIME_DIR)=' || true
故障复现时，OpenClaw Gateway 进程里只有：
XDG_RUNTIME_DIR=/run/user/1000
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
没有：
DISPLAY=:0
XAUTHORITY=/tmp/xauth_xxxxxx
XDG_SESSION_TYPE=x11
XDG_CURRENT_DESKTOP=KDE
这就解释了为什么终端明明在图形桌面里，OpenClaw 却无法打开可见浏览器：终端有图形环境，不代表已经运行中的 systemd 用户服务进程也有图形环境。
进程环境在启动时就固定下来。后面即使桌面环境正常了，已经启动的后台进程也不会自动获得新的环境变量。
通过重启复现问题
为了确认不是偶发状态，进行了重启测试。
重启后先查看系统启动时间：
uptime -s
再查看 OpenClaw Gateway 状态：
systemctl --user status openclaw-gateway.service --no-pager
故障状态下可以看到，电脑刚启动十几秒后，OpenClaw Gateway 就已经被自动拉起。随后检查进程环境，仍然只有：
XDG_RUNTIME_DIR
DBUS_SESSION_BUS_ADDRESS
没有 DISPLAY 和 XAUTHORITY。
这说明 OpenClaw Gateway 启动得太早：它作为用户服务在图形会话环境完全准备好之前就启动了。
查看 journal 日志
使用 journal 查看服务启动日志：
journalctl --user -u openclaw-gateway.service \
--since "$(uptime -s)" \
--no-pager
可以看到 OpenClaw Gateway 在开机后很快启动，并正常进入 running 状态。但这只是说明 Gateway 本身启动成功，不代表它具备打开图形窗口所需的环境。
后来还观察到一次服务被重启的情况。使用 verbose 日志查看：
journalctl --user -u openclaw-gateway.service \
--since "YYYY-MM-DD HH:MM:SS" \
--until "YYYY-MM-DD HH:MM:SS" \
-o verbose \
--no-pager
其中出现了：
JOB_TYPE=restart
这说明那次不是崩溃，也不是 Restart=always 自动拉起，而是 systemd 收到了一个 restart job。旧进程收到 SIGTERM 后干净退出，新进程随后启动。
重启后的新进程继承到了完整的图形环境，于是可见浏览器可以正常打开。这进一步说明：OpenClaw 本身没有坏，浏览器也没有坏，关键是 Gateway 进程启动时是否继承到图形会话变量。
原始服务的启动方式
查看服务文件：
systemctl --user cat openclaw-gateway.service
原始服务中可以看到类似：
[Install]
WantedBy=default.target
这意味着它被挂到用户 systemd 的 default.target 上。
default.target 是用户 systemd 管理器的默认目标，启动很早，并不保证 KDE 桌面、X11 授权文件、DISPLAY、XAUTHORITY 等图形环境已经准备好。
对于普通后台服务，这样启动没有问题；但 OpenClaw Gateway 既是后台服务，又需要控制可见浏览器窗口，所以它实际上依赖图形会话环境。
不采用复杂脚本修复
一种修复方式是使用 KDE Autostart，在桌面启动后执行一个自定义脚本，脚本中导入环境变量，再启动 OpenClaw Gateway。
这种方案虽然可行，但会引入额外复杂度：
~/.config/autostart/
~/.local/bin/自定义脚本
额外日志文件
额外启动入口
对于一个本来已经由 systemd 管理的用户服务来说，这种修复方式不够干净。更好的方案应该尽量保留在 systemd 用户服务体系内完成。
更干净的解决方案：改挂 graphical-session.target
KDE 会话中存在用户级图形会话目标：
systemctl --user status graphical-session.target --no-pager
如果它是 active，说明当前 systemd 用户会话中确实有图形会话 target 可以使用。
解决思路是：
不要让 OpenClaw Gateway 跟 default.target 太早启动；
改为让它跟 graphical-session.target 启动；
并声明它属于图形会话的一部分。
首先停止并禁用原来的早启动入口：
systemctl --user disable --now openclaw-gateway.service
确认状态：
systemctl --user is-enabled openclaw-gateway.service
systemctl --user is-active openclaw-gateway.service
然后把服务挂到 graphical-session.target：
systemctl --user add-wants graphical-session.target openclaw-gateway.service
再添加 systemd drop-in，不直接修改 OpenClaw 生成的原始 service 文件：
mkdir -p ~/.config/systemd/user/openclaw-gateway.service.d
cat > ~/.config/systemd/user/openclaw-gateway.service.d/override.conf <<'EOF'
[Unit]
After=graphical-session.target
PartOf=graphical-session.target
EOF
systemctl --user daemon-reload
这样做之后，服务结构变成：
graphical-session.target
└── openclaw-gateway.service
而不是：
default.target
└── openclaw-gateway.service
After=graphical-session.target 表示：如果两者都要启动，OpenClaw Gateway 应该排在图形会话 target 之后。
PartOf=graphical-session.target 表示：OpenClaw Gateway 生命周期上属于图形会话的一部分。图形会话停止时，它也可以跟着停止。这比把它作为普通后台服务长期独立运行更符合“需要可见浏览器”的用途。
验证挂载关系
设置后检查：
systemctl --user list-dependencies graphical-session.target | grep openclaw || true
systemctl --user list-dependencies default.target | grep openclaw || true
systemctl --user cat openclaw-gateway.service
理想状态是：
graphical-session.target 下可以看到 openclaw-gateway.service
default.target 下不再出现 openclaw-gateway.service
systemctl --user cat 中仍然可能显示原始 service 文件里的：
[Install]
WantedBy=default.target
这不一定代表当前仍由 default.target 拉起。它只是原始 service 文件中的安装建议。真正的当前挂载关系，应以 list-dependencies 和实际 wants 关系为准。
手动启动验证
当前图形会话已经正常时，手动启动服务：
systemctl --user start openclaw-gateway.service
然后检查实际进程环境：
PID="$(systemctl --user show -p MainPID --value openclaw-gateway.service)"
echo "PID=$PID"
tr '\0' '\n' < "/proc/$PID/environ" \
| grep -E '^(DISPLAY|XAUTHORITY|WAYLAND_DISPLAY|XDG_SESSION_TYPE|XDG_CURRENT_DESKTOP|DBUS_SESSION_BUS_ADDRESS|XDG_RUNTIME_DIR)=' || true
正常结果应包含：
DISPLAY=:0
XAUTHORITY=/tmp/xauth_xxxxxx
XDG_CURRENT_DESKTOP=KDE
XDG_SESSION_TYPE=x11
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_RUNTIME_DIR=/run/user/1000
随后进入 OpenClaw TUI：
oc
输入“打开浏览器”，可见浏览器成功打开。
这一步说明：只要 OpenClaw Gateway 在图形环境已经进入 systemd 用户环境之后启动，它就可以正常控制可见浏览器。
重启后最终验证
真正的验证必须重启系统。
重启后执行：
uptime -s
systemctl --user status openclaw-gateway.service --no-pager
systemctl --user is-enabled openclaw-gateway.service
systemctl --user list-dependencies default.target | grep openclaw || true
systemctl --user list-dependencies graphical-session.target | grep openclaw || true
PID="$(systemctl --user show -p MainPID --value openclaw-gateway.service)"
echo "PID=$PID"
tr '\0' '\n' < "/proc/$PID/environ" \
| grep -E '^(DISPLAY|XAUTHORITY|WAYLAND_DISPLAY|XDG_SESSION_TYPE|XDG_CURRENT_DESKTOP|DBUS_SESSION_BUS_ADDRESS|XDG_RUNTIME_DIR)=' || true
修复成功后可以看到：
openclaw-gateway.service active
Drop-In: override.conf
graphical-session.target 下存在 openclaw-gateway.service
进程环境中包含：
DISPLAY=:0
XAUTHORITY=/tmp/xauth_xxxxxx
XDG_CURRENT_DESKTOP=KDE
XDG_SESSION_TYPE=x11
然后再次运行：
oc
输入“打开浏览器”，浏览器成功打开。
问题本质总结
这次问题的本质不是 OpenClaw 损坏，也不是 Brave 浏览器损坏，而是 systemd 用户服务启动阶段和 KDE 图形会话环境之间的时序问题。
原始结构：
systemd --user default.target
↓
OpenClaw Gateway 很早启动
↓
进程没有 DISPLAY / XAUTHORITY
↓
无法打开可见浏览器
修复后结构：
KDE graphical-session.target
↓
OpenClaw Gateway 启动
↓
进程继承 DISPLAY / XAUTHORITY
↓
可见浏览器正常打开
最终采用的修复方式没有写死 DISPLAY=:0，也没有写死 XAUTHORITY=/tmp/xauth_xxxxxx，因为这些值属于当前图形会话，尤其 XAUTHORITY 是动态路径，硬写进 service 文件会埋下新的隐患。
也没有使用 KDE Autostart 或额外 shell 脚本，而是继续使用 systemd 用户服务自己的结构，通过 graphical-session.target 和 drop-in override 调整启动时机。这种方式更干净，也更符合 Linux 桌面系统中“服务归服务、图形会话归图形会话”的边界。
最终保留的配置
最终保留的是：
~/.config/systemd/user/openclaw-gateway.service
~/.config/systemd/user/openclaw-gateway.service.d/override.conf
其中 override 内容为：
[Unit]
After=graphical-session.target
PartOf=graphical-session.target
并通过：
systemctl --user add-wants graphical-session.target openclaw-gateway.service
让 OpenClaw Gateway 跟随图形用户会话启动。
这次排查的经验是：当一个 systemd 用户服务需要打开 GUI 程序时，不能只看终端里有没有 $DISPLAY，必须检查该服务实际进程的 /proc/<PID>/environ。真正决定它能否打开窗口的，不是当前 shell 的环境，而是服务进程启动时继承到的环境。