DeepSeek TUI 已改名为 CodeWhale
这个项目上游已经改名。现在的新安装命令应优先使用 npm install -g codewhale，启动命令也应优先使用 codewhale。
旧的 deepseek / deepseek-tui 目前仍作为兼容 shim 存在，但上游已经说明它们只是过渡方案，并计划在 v0.9.0 移除。
Homebrew 安装
如果你的 macOS CLI 工具大多由 brew 管理，Homebrew 会是更整洁的 CodeWhale 安装路线
如果你是搜 DeepSeek TUI 进来的，先记住当前上游已经改名为 CodeWhale。当 Homebrew 已经是你机器上的主要包管理层时，用它安装会让更新路径和二进制归属更清晰。
本页是站内详情页用 Homebrew 安装 CodeWhale（DeepSeek TUI 改名指南）安装
这页能直接回答的问题
- 什么时候 Homebrew 真能简化 macOS 上的安装故事？
- 怎样避免 brew 和其他安装路径抢同一个二进制？
- 哪些检查能说明当前真的走的是 brew 路线？
做完后该核对什么
- 重开终端后验证 `codewhale --version`。
- 检查 `/opt/homebrew` 或 `/usr/local` 顺序是不是把别的二进制挡住了。
- 二进制路径没确认前，不要急着往 provider 和配置层排。
最常见的误区
- 只是觉得 brew 方便，就选它，但你机器上真正长期管理 CLI 的其实是别的路径。
- 用 brew 更新，但实际生效的二进制还来自 npm 或 cargo。
- 没核对路径，就先去排 provider 错误。
推荐阅读顺序
先按当前问题走，再决定要不要切去相邻详情页或 hub。
先确认 brew 自己稳定
安装前先保证 `brew --version` 和你平时的 brew 安装流程本来就能正常工作。
谁安装谁更新
如果这次是 brew 安装，后面更新也尽量继续走 brew，不要半路改去 npm 或 cargo。
核对当前二进制路径
安装后马上查 shell 实际调用的是不是 brew 管理的二进制。
直接可用的示例
先拿可执行例子，再回头做更细的调整。
只通过 brew 安装并验证
让包归属保持单一。安装、重开 shell，然后确认当前活跃二进制确实来自 brew。
brew install deepseek-tui
codewhale --version
command -v codewhale || which codewhale检查当前生效的是哪条 Homebrew 前缀
在 macOS 上，很多混乱都来自 `/opt/homebrew`、`/usr/local` 或别的包路径先赢。
command -v codewhale || which codewhale
# 对照解析到的路径是不是你的 brew 前缀先确认 brew 自己健康，再怪应用
如果 brew 本身就有问题，先修它，不要把包管理器漂移误判成 DeepSeek TUI 安装问题。
brew --version
brew doctor
brew list | rg deepseek-tui || true常见失败分支
先判断你卡在哪一层，再去对应分支，不要把所有问题都混成一个。
brew 安装成功了，但命令仍然指向别处
这说明 Homebrew 还不是当前拥有者。先修 PATH 顺序，不要先把问题归到 DeepSeek TUI。
当前已经是 brew 二进制，但请求还是失败
那通常就不再是安装层问题了，直接去看 provider 设置或配置层。
`brew doctor` 在安装前就已经报很多问题
先把它当成 Homebrew 环境债务处理。brew 基线不干净，后面的安装验证就不可靠。
什么时候该离开这页
当你已经确认当前路线没问题，就不要继续停留在这页。安装线应转去配置，配置线应转去 provider 或排错，MCP 和模式线则应该转回真实工作流页。详情页的价值是把问题缩窄，而不是长期停留在解释层。