Server Browser Automation

在无桌面 Ubuntu 服务器上通过 XFCE 虚拟桌面和 Chrome 远程调试实现浏览器自动化及持久登录状态管理。

This package appears to implement what it claims (VNC/XFCE + Chrome remote debugging for OpenClaw), but there are important practical issues to review before installing: - The install.sh requires root/sudo and then uses whoami to decide which home directory to configure. If you run it with sudo it will configure root's home (~root) rather than your normal user. Prefer to run as root only if you intend the service for root, or modify the script to use SUDO_USER (or pass an explicit TARGET_USER) so configuration goes into the intended account. - The start-chrome.sh template uses a literal $(whoami) within a single-quoted here-doc; verify the produced script's paths match the actual user who will run it. - The installer will add system packages and the Google Chrome apt repo and start services that listen on network ports (VNC 5901, Chrome remote debugging 18800). Do not expose VNC or Chrome debugging ports to the public internet — use SSH tunnels, noVNC behind authentication, or firewall rules. - Back up ~/.openclaw/openclaw.json if present (the script does create a backup) and inspect changes the script will make. Consider running this in a disposable VM/container first rather than on a production server. - If you need the skill to run for a non-root user, edit install.sh to set VNC_USER from SUDO_USER (fallback to a provided username) and ensure file ownerships and paths are correct. If you want, I can point out the exact lines in install.sh to change (SUDO_USER handling and here-doc quoting) and draft a safer variant of the installer that targets a specific non-root user and doesn't rely on apt-key add.

Type: OpenClaw Skill Name: server-browser-automation Version: 1.0.0 The skill automates the setup of a VNC-based browser environment on headless servers, which involves high-risk security configurations. Specifically, `install.sh` and `SKILL.md` configure Google Chrome to run with the `--no-sandbox` flag and expose a remote debugging port (18800), which could allow unauthorized remote control if the server is not properly firewalled. While these actions are aligned with the stated purpose of browser automation, they introduce significant security vulnerabilities by bypassing standard browser isolation and exposing a control interface.