只有先搞清楚当前活跃二进制到底归谁管，更新 CodeWhale 才会简单

DeepSeek TUI 改名以后，大多数升级混乱都来自重复安装、旧命令残留和 PATH 遗留。正确的升级命令不是放之四海而皆准的，它取决于现在 shell 第一个解析到的活跃命令到底来自哪条包管理路径。

本页是站内详情页更新或升级 CodeWhale（DeepSeek TUI 改名后）安装

DeepSeek TUI 已改名为 CodeWhale

这个项目上游已经改名。现在的新安装命令应优先使用 npm install -g codewhale，启动命令也应优先使用 codewhale。

旧的 deepseek / deepseek-tui 目前仍作为兼容 shim 存在，但上游已经说明它们只是过渡方案，并计划在 v0.9.0 移除。

这页能直接回答的问题

怎么判断当前到底是哪条包路径在拥有这个二进制？
什么时候升级问题其实是重复安装问题？
升级完成后第一时间该核对什么？

做完后该核对什么

在新 shell 中确认 `codewhale --version` 已经变化。
检查旧安装路径是不是仍然排在 PATH 前面。
如果升级后行为异常，下一步先看配置兼容，而不是盲目重装。

最常见的误区

当前生效的是 cargo 或 brew，却跑了 npm 更新。
几个升级命令一起跑，最后自己都不清楚 PATH 是谁赢了。
把升级问题都归因于包管理器，而真正坏掉的是配置漂移。

直接可用的示例

先拿可执行例子，再回头做更细的调整。

谁安装谁更新

不要几个包管理器一起跑更新。先确认当前活跃二进制到底归谁管。

codewhale --version
command -v codewhale || which codewhale
npm install -g codewhale@latest
cargo install codewhale-cli --locked --force
brew upgrade deepseek-tui
codewhale update

重开 shell 以后再核对

只有在新终端里解析到的还是同一个二进制、而且版本已经变了，这次升级才算真的完成。

codewhale --version

常见失败分支

先判断你卡在哪一层，再去对应分支，不要把所有问题都混成一个。

你更新了，但版本号没变

通常说明你更新的是错误的拥有者，或者旧二进制还排在 PATH 前面。

版本号变了，但行为变怪了

这往往不是包管理器坏了，而是升级后配置或 provider 预期漂移。下一步去看配置兼容。

什么时候该离开这页

当你已经确认当前路线没问题，就不要继续停留在这页。安装线应转去配置，配置线应转去 provider 或排错，MCP 和模式线则应该转回真实工作流页。详情页的价值是把问题缩窄，而不是长期停留在解释层。