把远程终端塞进手机，这个需求并不新鲜。但cordless的做法一直有点“两头忙”：后台跑一个守护进程，前台搭配一套桌面GUI，再配一个手机应用，三件套才能正常协作。v0.6版却彻底推倒了这套曾经被当作默认选项的设计，转为“命令行优先”。这个急转弯到底发生了什么？

旧模式的支持者：守护进程+独立配对，看起来分工清晰
之前的cordless把“启动服务”和“连接设备”硬拆成两条命令。你需要先跑cordless pair生成配对密钥，接着分别在桌面端和手机端各自进行独立配对。它的逻辑自洽：守护进程躲在后面管理所有PTY会话，桌面端和手机端只是平等的“客户端”，谁也别依赖谁。当你关闭桌面界面，会话继续跑，远端手机仍然能接入——这类“后台存活性”曾经是它的核心卖点。

打开网易新闻 查看精彩图片

新思路的挑战：应该先变成一个真正的终端程序
但项目所有者的一个质问改变了方向：“cordless应该是一个CLI优先的东西。看看终端应用的设计，从那里提取功能。我想要一个安装器，启动后就是一个完整的终端界面，首页直接挂上一个配对用的QR码——现在我得单独跑cordless pair，再分别配桌面和手机，这完全违背了初衷。”这不是小修小补，这是一次彻底的门面重建。于是团队和AI模型Sol展开了一场漫长的辩论，最终砍掉原有入口，让cordless自己扮演终端角色。

什么变了：一码配对，终端即仪表盘
现在只需执行cordless，没有额外参数，就会弹出一个全屏终端仪表盘。首屏中央直接展示一个单次使用的配对QR码，附带倒计时。拿手机应用扫一下，设备立刻绑定。想换新码，按一下p就刷新。这套交互不再需要独立的配对命令，也没有另一个窗口等着你去伺候。仪表盘本身是对Warp、Windows Terminal这类现代终端应用的借鉴，但并没有笨拙地再造一个轮子，而是一个高度聚焦的文本用户界面：↑/↓选择会话，Enter接入，n新建shell或启动Claude、Codex等编码代理，x终止，d管理已配对设备，q退出。它是一个薄客户端，背后还是那个持久化守护进程。退出仪表盘甚至关闭整个终端窗口，都不会导致后台会话或手机连接中断——守护进程仍然持有所有PTY。Sol特别强调这层边界不能模糊，这也是合理的坚持。

在终端里直接接管会话，不再需要第二套渲染器
按下回车——或者执行cordless attach ——会话流会被直灌进你的宿主机终端。没有xterm.js，没有次生渲染引擎。原始击键直送PTY，窗口大小调整事件前传，断开快捷键是Ctrl-] d。这就像一个极简的tmux式附着机制，全部复用手机端早已使用的回放/快照协议。此时宿主终端本身就是渲染器，cordless只是搬运字节流。

配对密钥回归守护进程，切断远程冒用路径
旧版cordless pair通过直接写文件的方式生成密钥。Sol指出这存在隐患：两个进程往同一个存储里铸造密钥，容易引发竞态和不一致的速率限制。v0.6于是统一成一条WebSocket通道上的pairing.create认证端点，但只有从真实回环套接字绑定的回环凭证才能调用——即只有本机所有者，手机端无权触发。密钥依旧是256位、单次使用、五分钟有效存活期，并且受速率和总量封顶。被盗取的手机令牌无法注册新设备，能施放配对权限的始终是坐在机器前的那个人。

一个二进制文件交付全部运行环境
“一个能直接用的安装器”背后藏着一个最严峻的要求：用户不能先装Node。v0.6把cordless自己的Node运行时和关键的node-pty原生模块全部打进了一个自包含的二进制文件，不再需要任何外部依赖。下载、赋权、运行，一步到位。