这个版本更新了什么#
chore(release): v0.1.19
"The Codex CLI could not be found on this machine" — when it was right there#
If your Node came from a version manager — mise, nvm, asdf, volta, fnm — Mochi
could not see the Codex CLI, and said so on the machine's page while which codex in your terminal printed the path.
An application launched from the Dock is handed a minimal PATH by macOS, not the
one your shell has. Mochi searched that, then a list of the usual places, then
asked npm where it puts global binaries — and on those machines npm is in the
same invisible directory, so the last resort could not run either.
It now asks your login shell for its PATH once at startup and adds whatever it
was missing. Everything follows from that: finding Codex, asking npm, and
actually running Codex to look something up.
If this was you, the settings page should simply be right after updating.
Nothing to configure, and nothing to reinstall.
Three details, because they change what to expect:
- 你原有的 PATH 仍然排在最前面。这个改动只会新增几个查找的位置，所以不会 that already resolved changes meaning.
- 终端反应慢、或者干脆不回应，都不算出错。Mochi 会保留原来的 PATH it had and carries on.
- Windows 上不受影响：在那里，程序本来就能拿到真正的 PATH。
Why the fix is this and not a longer list of folders#
Mochi already carried a list of well-known directories, and nvm had needed its
own entry in it. mise was the second, with asdf, fnm, volta and bun behind it —
so the list was going to keep losing.
And finding the file would not have been enough on its own. The Codex binary an
npm install leaves behind starts with #!/usr/bin/env node, and the node it
wants is in the same directory the app could not see. Located by folder and run
anyway, it fails — and Mochi would have told you the CLI was broken and to
reinstall it, which is worse advice than saying it was missing.
以上译自作者写在 GitHub 上的英文更新说明。查看原页面