当初的问题#

敲错命令时，终端不是立刻报 command not found，而是沉默很久。当时的判断是 mise 的命令接管机制太重，于是选择”新终端默认绕开 mise”：

核心机制#

新终端
  ↓
MY_DISABLE_PYTHON=1, MY_DISABLE_NODE=1
  ↓
MISE_DISABLE_TOOLS=python,node
  ↓
which python → /usr/bin/python（系统版本）

执行 mise use python@3.14
  ↓
unset MY_DISABLE_PYTHON → MISE_DISABLE_TOOLS=node（只禁 node）
  ↓
python 切到 mise 管理，node 保持系统版本

实现要点：一个包装 mise 函数的 zsh 脚本（~/.config/mise/mise.zsh），检测 mise use 的参数，自动解开对应工具的禁用开关；配合 mise-python-enable/disable、mise-node-enable/disable、mise-status 等手动控制函数。

为什么废弃#

这个方案治标不治本——它回避的是”mise 接管错命令”这个现象，而不是现象背后的病根。绕道本身还引入了维护成本：mise 函数包装、开关变量、状态函数一整套自造轮子。2026-11-08 排查清楚根因后，整套配置删除。

卡死的完整链条#

敲错命令
  ↓
zsh 查不到 → 触发 command_not_found_handler
  ↓
这个 handler 是 mise activate 注入的（经 ~/.config/shell/inits）
  ↓
handler 调用 mise hook-not-found
  ↓
mise 扫描 /etc/mise/conf.d/omarchy-tools.toml 声明的 ~30 个 AI CLI 工具
  ↓
每个工具都是 @latest → 版本信息不在本地 → 联网查 GitHub / npm / x.ai / api.meta.ai
  ↓
直连网络下部分域名被墙黑洞（TCP SYN 发出去石沉大海）
  ↓
mise 的 HTTP 层：30 秒超时 × 3 次重试 ≈ 2 分钟静默
更糟的情况：TCP 层无连接超时 → SYN-SENT 永久挂死
  ↓
终端卡住，最后才报 command not found

设计意图能理解：mise 的卖点是”敲一个没装过的工具名，自动帮你装好再执行”。但代价是每次敲错命令都可能触发一轮全量联网扫描，且对网络故障没有任何快速失败机制。

为什么时好时坏#

三个变量叠加，让问题表现得像随机：

实测对比#

代价#

只失去一件事：敲一个没装过的工具名，mise 不再自动安装。需要时手动 mise install 或 mise use -g。已装好的工具完全不受影响——日常执行走 PATH，不经过这个 handler。Python / Node 的版本管理照常工作，只是不再需要懒加载开关来控制”谁接管谁”。

1. 老 shell 不吃新配置#

handler 是函数，在 shell 启动时注入体内。修复后已经开着的终端（尤其 herdr/tmux 这类常驻会话里的 shell）要 exec zsh 或重开才干净。

2. 常驻 server 同理#

herdr 这类终端管理器的 server 是长驻进程，reload-config 只对 UI 配置生效；涉及启动行为的配置段（如 [update]）要等 server 重启才真正生效，详见上文 herdr 一节。

3. 验证时别被缓存骗了#

血泪教训：自己开个新 shell 测”秒回”不代表修好了——可能只是 mise 失败缓存还热着。必须在用户实际使用的那个进程里验证，或用 0.5 秒采样的监视器抓现行（盯 pgrep -x mise、ss -tnp state syn-sent）。