很多人已经接受了一个事实：真正高频写代码的 AI 体验，越来越不在网页里，而在终端里。codex、claude、gemini、opencode 这些 CLI 工具跑起来之后，确实能把大量开发工作压到一个 shell 里完成。

但问题也很快出现了。你真正难管理的，往往不是某一个模型，而是它们周围那一圈越来越乱的上下文：

  • 一个项目里开了多个终端；
  • 平行任务拆成了多个 worktree；
  • 每个工具各自维护历史、状态和恢复方式；
  • token 花费分散在不同地方；
  • 远程机器和本地机器来回切换；
  • 中断过几小时后，再回来很难接上原来的工作。

今天想写的 duxweb/codux，就是冲着这层“CLI 周边混乱”去的。它不是再做一个 AI 编辑器，而是把 AI 编程 CLI 的工作台 独立出来：你继续在终端里跑熟悉的工具，但项目、worktree、会话状态、统计、记忆和远程访问，被统一收进一个原生桌面壳里。

发布时 GitHub 仓库页显示这个项目约有 104 stars、12 forks，语言分布以 Rust 为主。仓库公开页当前给出的最新 release 是 v1.9.1，发布时间为 2026-06-18。README 把它定义成一个 为 AI coding agents 构建的原生终端。

项目概览

属性详情
仓库duxweb/codux
定位面向 AI 编程 CLI 的项目感知原生工作台
Stars约 104
Forks12
主要语言Rust
桌面技术栈Rust + GPUI
最新 releasev1.9.1
支持平台macOS 14+、Windows 11

它解决的不是“怎么再包一层聊天框”，而是“CLI 工作流怎么别失控”

Codux AI 最有意思的一点，是它没有试图说服你离开现有 CLI。README 的核心判断很直接：AI coding CLI 很强，但一旦进入真实项目，状态会散得很厉害。

这个判断是对的。因为很多团队今天的真实形态已经不是“一人一个 IDE + 一个 AI 面板”，而更像：

  • 主项目里跑一个 agent；
  • 另外开几个 worktree 做并行修复；
  • 某些任务要切到远端机器；
  • 不同 CLI 的 resume、history、memory 注入方式又不一样。

codux 的做法不是发明一套全新的对话入口，而是把这些已经存在的 CLI 工作流，变成一个更可恢复、更可观察的桌面工作台。这种定位比“再做一个 AI IDE”要务实得多。

支持多种 CLI，但真正重要的是“项目感知”

README 当前列出的已接入工具包括：

  • Codex
  • Claude Code
  • Gemini CLI
  • OpenCode
  • Kiro CLI
  • Kimi Code
  • CodeWhale
  • Agy

很多产品说自己“支持多个 AI 工具”，其实只是把多个命令入口并排摆着。codux 更有价值的地方，在于它把这些 CLI 放进同一套 project-aware 模型里。

它强调的不是“有几个 provider”，而是：

  • 会话绑定到具体项目和 worktree；
  • 工具状态能被统一展示；
  • 历史和恢复路径尽量收敛；
  • 记忆和项目上下文可以被自动注回支持的 CLI。

换句话说，重点不是多工具本身，而是 多工具不再各自漂着。

worktree-first 这件事，比“多标签终端”重要得多

README 里我最认同的一点，是它明确把模型写成：

Project → Worktree / Task → Terminals, Files, Git, AI Sessions

这个顺序很关键。很多终端工具默认还是“标签页容器”的思路，开再多 pane，本质上也只是把 shell 摆在一起。可 AI 编程场景里，真正需要隔离的是任务，不只是窗口。

codux 在这里做的事情更接近真实工程组织：

  • 为并行任务创建独立 Git worktree；
  • 把终端、文件、Git 状态和 AI 会话都跟 worktree 绑定；
  • 任务切换时把布局和上下文一起带回来；
  • 做完后可以 review、merge，再清理 worktree。

如果你已经习惯把“每个 agent 任务都放进一个 worktree”，那这个方向会很顺手。它把原本靠人脑维护的状态边界，往工具里推进了一层。

它最像开发工具的地方，是把“可见性”补上了

很多 AI CLI 的问题，不是能力不够，而是运行起来之后你很难知道它到底在做什么、花了多少钱、现在卡在哪。

README 里反复强调几类能力：

  • 实时 agent 状态；
  • 本地历史和 session restore；
  • 按工具、模型、项目、worktree、日期统计 token 用量；
  • 当 CLI 暴露计划信息时，直接显示任务计划；
  • 把记忆抽取、本地项目画像和模块笔记注回支持的工具。

这些功能单看都不新，但组合在一起就很有价值。因为它们补的不是“更会生成代码”，而是 让长时间 agent 工作更可审计、更可继续。

对真正拿 CLI 连续跑几小时任务的人来说，这通常比再多一个模型切换按钮更重要。

本地记忆和安全 SSH 的方向很对

codux README 里有两点我觉得特别实用。

第一是 memory kept local。它提到会从会话里提取偏好、项目画像和模块笔记，但会把历史和记忆留在本机。这对长期使用者来说很关键，因为很多上下文确实应该服务于后续工作，但不一定适合离开当前设备和当前项目边界。

第二是 agent-safe SSH。它通过保存和测试 SSH profile，再提供 codux-ssh 这种入口，让 agent 可以执行远程命令，同时不直接看到你的密码或私钥。

这类设计很像真正做过长期 agent 运维的人才会补上的细节。因为一旦 AI 真开始替你碰服务器，权限和凭据边界就不能再靠“自己小心一点”来维持。

手机接管和原生技术栈，让它跟一般终端壳子拉开了距离

README 里还有两个让我觉得它不是普通包装层的点。

第一是 phone-to-desktop handoff。它允许手机和桌面配对，在你离开电脑时继续控制仍然跑在桌面上的项目、终端和 AI 会话。很多人会把这当作附加功能，但对长时间 agent 任务来说，这其实很合理：任务留在主机上继续跑，人只是换了控制端。

第二是它明确强调 Rust + GPUI，而不是 Electron。作者想要的是重终端负载、长会话和跨项目切换下仍然保持顺滑。这一点至少从定位上说得通，因为 AI CLI 工作台最怕的就是外层壳子先变成性能瓶颈。

最近 release 暗示它正在从“能用”走向“更稳”

从公开的 v1.9.1 release 说明来看，这一版虽然不是大功能发布，但修的点都很像一个正在打磨长期工作流的项目：

  • 刷新桌面端和移动端 README 与下载入口；
  • 修复桌面端 / 移动端 terminal viewport handoff；
  • 修复移动端自绘终端字符缺失和重叠；
  • 修复多种 AI runtime probe 的 running / loading 状态稳定性。

这些改动没有“宣传页式”的华丽感，但都很接近真实使用里的痛点。尤其是 runtime probe 和 terminal handoff，这正是这种工具最容易在实际运行中露出毛刺的地方。

它适合谁

如果你的日常已经开始出现这些情况：

  • 同时使用两个以上 AI 编程 CLI；
  • 一个项目里经常并行跑多个 agent 任务；
  • 习惯用 Git worktree 隔离任务；
  • 需要持续看 token 消耗和会话状态；
  • 会让 agent 碰远端机器，但又不想直接暴露凭据；

那 codux 很值得试一下。

反过来，如果你还主要停留在“偶尔在终端里问几句 AI”的阶段，那它的很多设计可能暂时用不上。因为它明显不是给轻量补全场景做的，而是给 已经把 CLI 当主战场的人 准备的。

小结

duxweb/codux 真正值得看的，不是“又一个 AI 工具外壳”，而是它把 AI 编程 CLI 周围最容易失控的那部分工程现实，认真组织了起来：project-aware 终端、worktree-first 任务模型、统一可见性、本地记忆、安全 SSH、跨设备接力。

它现在 stars 还不高，但方向已经很清楚了。如果你相信未来一段时间最强的 AI 编程体验仍然主要发生在 CLI 里，那这类“给 CLI 做工作台”的项目，大概率会越来越重要。