code 命令不支持 ssh:// 协议，因其仅解析本地路径和 file:// 或已建立连接后的 vscode-remote:// URI；远程路径需在已通过 Remote-SSH 连接的窗口中执行 code /remote/path，或使用 code tunnel 实现纯命令行远程访问。
不能直接用 code 命令打开远程项目——它只处理本地路径，不解析 SSH 或容器地址。
为什么 code ssh://user@host/path 不起作用
VS Code 的命令行工具 code 默认只支持本地文件系统路径。它不认识 ssh://、dev-container+ssh:// 这类协议前缀，强行传入会报错 Unable to open 'xxx': File not found 或直接忽略远程部分，只尝试打开本地的 ssh: 子目录。
- Remote-SSH 插件的连接逻辑完全在 UI 层（命令面板或 Remote Explorer）中触发，不暴露为命令行可调用的入口
-
code --folder-uri仅支持file://和vscode-remote://协议，而后者需要先建立连接、生成有效 URI，无法手写构造 - 试图用
code --remote "ssh-remote+user@host"是无效的——该参数不存在，VS Code 会静默忽略
code 命令能做的唯一远程相关操作：在已连接状态下打开远程文件夹
前提是当前 VS Code 窗口已通过 Remote-SSH 成功连接到目标主机，并且该窗口处于激活状态。此时可在终端中执行：
code /path/to/remote/project
这个路径是远程机器上的绝对路径，不是本地路径。VS Code 会把该请求转发给已运行的远程服务端，等效于在资源管理器里点击“Open Folder”。
- 必须确保当前终端环境变量
VSCODE_IPC_HOOK或VSCODE_PID可被识别（通常由已打开的 VS Code 实例自动注入） - 如果 VS Code 是通过桌面图标启动的，Windows/macOS 上的终端可能拿不到上下文，建议从 VS Code 内置终端中执行该命令
- Linux 下若使用
code --no-sandbox启动过，后续code /path可能复用沙盒进程，但行为不稳定，不推荐依赖
真正可靠的命令行远程打开方案：用 code tunnel
如果你的目标是“纯命令行驱动、无需 GUI 点击”，code tunnel 是目前唯一官方支持的路径。它适用于 Dev Containers 或远程服务器上已运行 VS Code Server 的场景：
- 先在远程机器上运行：
code tunnel --accept-server-license-terms（首次需同意协议） - 它会输出一个类似
https://abcd1234-3000.githubpreview.dev的访问链接 - 本地浏览器打开该链接，或用
code --reuse-window在已有 VS Code 窗口中加载 - 注意：
code tunnel依赖远程机器上已安装 VS Code Server，且默认监听 localhost:3000；如端口被占，需加--port指定
该方式绕过了 SSH 配置和密钥管理，但要求远程机器可访问公网或内网 DNS 可解析，不适合严格隔离的生产环境。
容易被忽略的关键点
所有远程开发模式（SSH / Tunnels / WSL / Dev Containers）都依赖远端运行的 vscode-server。它不是全局常驻服务，而是按需拉取、按用户隔离部署在 ~/.vscode-server 下。这意味着：
- 第一次用 Remote-SSH 连接时，VS Code 会在远程自动生成并安装 server，耗时较长，且需要远程有 curl/wget 和解压工具
- 手动删掉
~/.vscode-server后，下次连接会重新下载，但不会自动重装插件——插件是客户端决定是否同步的 - 如果你在远程机器上用
systemctl --user start code-server手动启了服务，那和 Remote-SSH 的 server 冲突，会导致连接失败或功能异常
