Codux 采用与安全审计清单：从适配器、worktree 到远程 Beta 的落地边界
面向团队采用 Codux AI 编程终端的中文安全审计清单：支持系统、CLI 适配器矩阵、worktree 纪律、凭据 profile、远程 Beta、恢复演练与信任验证。
先审计，再把 Codux 放进团队工作流
Codux 的定位很容易被一句“AI 编程终端”带偏。对个人开发者来说，它确实是一个原生终端；但对准备在团队里采用 AI coding CLI 的工程组织来说，它更像一个把 Codex、Claude Code、OpenCode、Kimi Code、Kiro CLI 等工具收进同一工作区的控制平面。官方仓库把 Codux 描述为“native connected terminal for AI agent development”，官网与 README 又强调 Rust + GPUI、实时状态、Token 统计、本地记忆、凭证隔离的 SSH / 数据库访问、手机与主机端加密互联。这些能力很适合长时间、多任务、跨设备的 Agent 编程，但也意味着上线前不能只看 UI 是否顺手，而要做一次采用与安全审计。
这份清单的核心判断是：Codux 不应该被当作一个随便安装的开发小工具，而应被纳入“能运行命令、能管理会话、能连接服务器、能查询数据库、能影响代码仓库”的开发基础设施。审计重点不是阻止使用，而是把使用边界讲清楚：哪些系统可安装，哪些适配器可启用，worktree 如何约束并行任务，凭据配置如何分层，远程 Beta 能否进入生产路径，异常中断如何恢复，以及团队如何验证一个下载包、一次配对和一条代理会话确实可信。
一、系统与安装面：先确认支持平台和发布来源
采用 Codux 的第一步，是把“谁能安装、从哪里安装、安装哪个形态”写清楚。官方 README 的下载区给出桌面端 macOS Apple Silicon、macOS Intel、Windows 11 x64；官网首页也标出桌面端为 macOS 与 Windows，主机端为 Linux、macOS 与 Windows，移动端为 Android 与 iOS。主机端 README 进一步说明 codux-agent 跨平台运行于 macOS、Linux、Windows，支持 x86_64 与 arm64，服务安装分别面向 launchd、systemd --user 和 Windows Task Scheduler。也就是说，桌面 GUI 与无界面主机端的支持面并不完全相同，团队不能把“平台徽章写了 macOS | Windows | Linux”简单理解为每个形态都等价。
安全审计建议把安装来源分成三类。第一类是官方 GitHub Releases，例如 latest release 与具体版本页 v2.0.3；第二类是官方文档中的 Homebrew 安装命令 brew install --cask duxweb/tap/codux；第三类是主机端一行安装脚本 curl -fsSL https://raw.githubusercontent.com/duxweb/codux/main/apps/agent/scripts/install.sh | sh。团队环境里，第一类最适合做版本固定和哈希校验，第二类适合个人桌面快速安装但仍需锁定 tap 来源，第三类因为是管道执行脚本，应只在受控机器、可审查脚本内容、可固定版本的前提下使用。GitHub Release API 为资产提供 sha256 digest，这一点应该纳入下载校验，而不是只看文件名是否像官方包。
二、适配器矩阵：不要把“支持 AI CLI”理解成能力相同
Codux 的价值来自多 AI CLI 统一视图，但审计时必须逐项看适配器矩阵。官方 README 明确写着它使用非侵入式 wrappers 与 per-tool adapters，不会为了注入上下文而写项目提示词文件，也不会修改全局 AI CLI 配置。矩阵显示 Codex、Claude Code / reclaude、Oh My Pi、OpenCode、MiMo Code、Kimi Code、Kiro CLI、CodeWhale、Agy 在实时状态、Token 用量、模型设置、完全权限模式和环境指令注入上的支持并不一致。
推荐把适配器审计写成表单，而不是口头约定。Codex 支持实时状态、Token、模型设置、完全权限模式，并通过 developer instructions 注入环境指令；Claude Code / reclaude 与 Oh My Pi 通过 --append-system-prompt；OpenCode、MiMo Code 通过 Codux 托管的 plugin 配置；Kimi Code 通过托管 --agent-file，但完全权限模式在矩阵里不是勾选；Kiro CLI、CodeWhale、Agy 虽有状态、Token 与模型设置等支持，但环境指令注入受限或未确认。这里的治理含义很直接：如果团队依赖 codux-ssh、codux-db 或本地记忆指令，不能假设所有 CLI 都能同样接收这些环境边界；如果某个工具“不注入”，就应把它列入只做会话追踪、不得执行凭据相关任务的类别。
适配器矩阵还要区分“可观测”和“可授权”。实时状态、Token 统计可以帮助团队观察会话是否失控，但并不等于授权模型访问生产资源。模型设置可以降低误用成本，但也不等于审计了提示词注入路径。完全权限模式更应单独审批：只有在独立 worktree、低风险仓库、凭据只读或无凭据、测试可回滚时才允许打开。对首次采用 Codux 的团队，建议先启用一个主力 CLI 做试点，确认状态、历史、Token、内存注入和恢复都符合预期，再扩大到更多适配器。
三、worktree 纪律：让每个 Agent 任务都有隔离现场
Codux 官方材料反复强调 worktree-first model：每个任务保留自己的终端、Git 状态、文件和 AI 会话。这对安全与质量都很关键。AI 编程最大的风险之一，是多个长会话在同一个工作目录里交叉修改，最后没有人能说明哪个变更来自哪个任务、哪条测试对应哪个版本、哪段回滚会误伤另一个代理的中间成果。worktree 不是花哨功能，而是团队采用 Codux 前必须固化的纪律。
建议把每个代理任务命名为“工单号或目标 + 风险级别 + 负责人”，并在独立 worktree 内运行。主分支只接受人类审查后的合并；任何 Agent 会话都不得直接在主工作区执行大范围重构；同一缺陷可以允许多个 worktree 并行试验，但必须在合并前比较 diff、测试输出和会话历史。Codux 的项目视图、Git 状态、会话恢复与 Token 统计都应服务于这个目标：让团队能回答“谁让哪个代理在什么隔离目录里做了什么”。
回收 worktree 也要有流程。任务完成后，先保存会话摘要、测试命令、关键 diff 和人工审查结论；确认不需要恢复后再删除 worktree。失败任务不要直接抹掉，至少保留导致失败的日志与原因，因为这些记录能帮助团队改进提示词、权限策略和测试门槛。若任务接触数据库、SSH 或远程主机，还应在 worktree 关闭前确认没有后台进程、隧道、临时密钥或未提交配置文件残留。
四、凭据配置：让模型只看到配置名，不看到秘密
Codux 最值得单独审计的能力，是凭证隔离的 codux-ssh 与 codux-db。官方 README 写得很明确：Agent 执行 codux-ssh list 时只能看到 profile 名称和主机，密码与密钥由 Codux helper process 注入，不进入模型上下文、会话记录或 shell 历史；数据库侧支持 MySQL、PostgreSQL、SQLite，只读 profile 由 wrapper 用单语句 allowlist 强制执行，模型不能自行提权。这比把密码复制进提示词安全得多，但仍需要团队制定 profile 规则。
第一条规则是按环境分层：local、dev、staging、production 必须分开命名，生产 profile 默认不暴露给 Agent 工作区。第二条规则是按权限分层：数据库优先创建只读 profile，写权限只给迁移或运维场景，并要求人工在会话外执行最终命令。第三条规则是按任务分层：一个 Agent 任务只获得本任务需要的最小 profile 名称，不能让“全部服务器”和“全部数据库”一起出现在可用列表里。第四条规则是定期轮换与删除：离职、项目结束、设备丢失、配对取消后，Codux 本地 profile、远程密钥和数据库账号都要一起清理。
还要注意，凭据不进入模型上下文并不代表查询结果无风险。只读数据库如果返回用户邮箱、订单、日志 token 或内部路径，模型仍可能在回复、历史或生成文件中泄露敏感数据。因此 codux-db 的 adoption checklist 应包含脱敏视图、最小表权限、结果行数限制、禁止导出、禁止把查询结果写入仓库，以及对生产数据默认使用聚合统计而不是明细行。
五、远程 Beta：把移动接力和主机端当成受控实验
Codux 的“一套工作区，多端互联”很吸引人：桌面、手机和主机端作为 peer，通过端到端加密的 P2P / relay 链路连接；能直连就直连，不行则中继；不需要公网 IP；连接主机后可以像本地一样驱动终端、Git 和 AI。主机端 README 又说明，host_id 与 host_token 生成后会作为稳定身份，配对票据存在 pair-ticket.json，设备信息在 devices.json，状态、锁和日志都在 ~/.codux-agent 或 $CODUX_AGENT_DATA_DIR。这些设计适合远程接续长任务，但官方也明确把 headless host 标为 Beta。
因此，团队不应一开始就把远程 Beta 放进生产运维链路。更稳妥的策略是：第一阶段只在非生产仓库和测试服务器验证配对、断线重连、终端恢复、Web Tunnel Browser 与诊断页；第二阶段允许连接 staging 主机，但禁用生产数据库写 profile；第三阶段如果要用于生产值班，必须增加设备清单、配对票据生命周期、日志留存、远程浏览器访问范围和应急撤销流程。手机端尤其要纳入移动设备管理：锁屏、丢失擦除、系统更新和 App 来源都应被审计。
对 Web Tunnel Browser 也要划边界。官方说明它会以主机身份访问网络，打开主机本地的 Vite、HTTPS、WebSocket、HMR、局域网、.local 和 VPN 路由；诊断页为 http://127.0.0.1:8765/。这很方便，但也意味着控制端可能间接访问只有主机可见的内网服务。采用前应规定：不得在隧道浏览器中登录生产后台，不得访问未授权内网页面，测试本地服务时要记录主机、端口、时间和任务编号。
六、恢复与应急：验证 session restore，而不是相信它
Codux 提供本地历史、session restore、断线后恢复同一批 shell 和 Agent 会话的能力；主机端还用 single-instance lock 避免重复启动，服务安装支持登录自启与失败重启。这些能力能显著降低长任务中断的损失，但安全审计必须把“恢复”当作需要演练的能力，而不是营销承诺。试点阶段就应设计恢复演练：关闭桌面端后重开、网络断开后重连、主机端服务重启、手机接管后再回桌面、AI CLI 异常退出、worktree 被删除或分支被移动。
每次演练都要记录三个结果：会话是否还在，文件是否处于可解释状态，凭据与远程连接是否被正确收回。恢复不是只看终端还能不能显示，还要看后台进程是否继续写文件、数据库查询是否继续运行、SSH 会话是否保持、Token 统计是否能定位异常消耗。若恢复后无法说明状态，团队应默认进入保守模式：停止相关进程、冻结 worktree、导出日志、人工检查 diff，再决定继续或废弃。
反馈与诊断也应纳入应急流程。官方 README 建议提交 bug 时使用“帮助 → 导出诊断包”，并列出 macOS 与 Windows 的日志路径，例如 ~/Library/Application Support/Codux/logs/runtime-rust.log、performance-summary.json 和 %APPDATA%\Codux\logs\runtime-rust.log。这些日志对排错有用，但可能包含路径、项目名、主机信息或错误上下文，发送给外部 issue 前要先脱敏。
七、信任验证：开源、版本、哈希、隐私与本地边界一起看
Codux 是 GPL-3.0 开源项目，仓库主页、官网、文档、移动端仓库、Issue 与 Releases 都是可验证入口。采用前应建立一套信任验证步骤：从 duxweb/codux 进入，不从第三方下载站拿包；核对官网 codux.work 与文档 Getting Started；固定 release 版本；核对 Release 资产名、架构、发布时间和 sha256 digest；在 macOS、Windows 或 Linux 上分别做最小启动测试；对主机端脚本先下载审查再执行，避免盲目 pipe to shell。
隐私边界同样要验证。官方 README 强调本地优先：项目、终端、会话、记忆、Token 统计和凭据都留在自己的机器上，没有 Codux cloud，也不需要账号；设备链路端到端加密，中继只转发密文；上下文注入经由 wrapper 与 adapter，不写仓库提示词文件，不修改全局 AI CLI 配置。团队应把这些声明转化为本地检查：安装后查看配置目录，确认仓库没有被写入未知 prompt 文件；启动支持的 CLI 后确认环境指令来源；创建 SSH 与 DB profile 后确认会话记录不含密码；远程配对后确认 paired devices 可列出、可删除、可清空。
八、采用结论：适合重度 Agent 工作流，但要分阶段开放
Codux 最适合的采用场景，是已经在认真使用多个 AI coding CLI、经常跑长任务、需要 worktree 隔离、需要跨设备接续、并且愿意把凭据访问纳入 profile 管理的团队。它不适合作为“每个人随便装一下”的工具，也不适合在没有 Git 纪律、没有凭据分级、没有日志脱敏、没有恢复演练的组织里直接接入生产资源。
推荐的落地顺序是：先在个人或小组试点桌面端，确认 macOS 或 Windows 安装、单一 CLI 适配、worktree 纪律和 Token 统计；再启用 codux-ssh 与只读 codux-db，验证凭据不会进入上下文；随后测试手机接力和主机端 Beta，但只连接非生产机器；最后才评估是否把 staging 或生产运维纳入 Codux，并为远程配对、设备撤销、日志保留和事故恢复建立制度。这样使用 Codux，重点不是追逐“AI 终端”的新鲜感，而是把 AI Agent 编程从不可控的黑箱，变成可隔离、可恢复、可审计的工程流程。