[Bug]: On macos, the od command conflicts with internal commands, making it unusable

[BWrong]

Before you submit

• I searched existing issues and confirmed this is not a duplicate.
• I replaced the example text with the real behavior, reproduction steps, expected result, and version from the app's About menu or od --version.

What happened?

On macos, the od command conflicts with internal commands, making it unusable，Execute od mcp install claude,error od: claude: No such file or directory

Steps to reproduce

1. open terminal；
2. input od mcp install claude

Expected behavior

Install mcp

Open Design version

0.13.0

Platform

macOS (Apple Silicon)

Logs (optional)

Screenshots (optional)

No response

Additional context

No response

[open-design-bot]

🎉 ✨ Welcome to Open Design, @BWrong!

✨ 🔥 Lit the spark.

🌱 Your first contribution adds energy to the project. Thanks for showing up and helping Open Design grow.

💛 Thanks for helping Open Design grow. Keep building in the open. 🚀

🔗 Share on X (English) · 分享到 X（中文）

[lefarcen]

Hey @BWrong, thanks for the clear repro — od mcp install claude turning into od: claude: No such file or directory on macOS looks like a real od path-collision issue, not just a bad command.

We already hit the same class of problem on WSL in #4648 / PR #4655, and the current MCP install code explicitly treats macOS/Linux shadowing as a case we need to handle (apps/daemon/src/mcp-routes.ts notes that the system octal-dump od can win on PATH). So this is at least a solid working hypothesis from the repo side as well.

As a short-term workaround, the Settings → MCP server panel should generate an absolute-path snippet that avoids relying on bare od. If you have a minute, could you also paste the output of type -a od and how you installed Open Design on this machine (desktop app vs source checkout)? That will tell us whether /usr/bin/od is winning on your PATH or whether there is a separate macOS packaging gap here.

Appreciate the report — this is useful to tighten up the macOS install path.

[BWrong]

Hey @BWrong, thanks for the clear repro — od mcp install claude turning into od: claude: No such file or directory on macOS looks like a real od path-collision issue, not just a bad command.

We already hit the same class of problem on WSL in #4648 / PR #4655, and the current MCP install code explicitly treats macOS/Linux shadowing as a case we need to handle (apps/daemon/src/mcp-routes.ts notes that the system octal-dump od can win on PATH). So this is at least a solid working hypothesis from the repo side as well.

As a short-term workaround, the Settings → MCP server panel should generate an absolute-path snippet that avoids relying on bare od. If you have a minute, could you also paste the output of type -a od and how you installed Open Design on this machine (desktop app vs source checkout)? That will tell us whether /usr/bin/od is winning on your PATH or whether there is a separate macOS packaging gap here.

Appreciate the report — this is useful to tighten up the macOS install path.

1. 
2. desktop app

[lefarcen]

Thanks — the desktop app detail is the useful part here. That makes this look less like the WSL/source-checkout docs problem from #4648 and more like a real macOS desktop install gap: your shell is still resolving the system od, while Open Design is apparently not giving Terminal an OD-backed od command to win on PATH.

The MCP panel is supposed to avoid that by generating an absolute-path launch command instead of relying on bare od, so if the desktop app is still leading you to od mcp install claude on macOS, that’s a bug worth fixing.

Could you paste the text output of type -a od from the screenshot, and also the exact Claude install snippet shown in Settings → MCP server? That will let us separate two cases quickly: (1) the panel is still emitting bare od ... on macOS, or (2) the panel is fine and only the manual command path is broken.

[BWrong]

Thanks — the desktop app detail is the useful part here. That makes this look less like the WSL/source-checkout docs problem from #4648 and more like a real macOS desktop install gap: your shell is still resolving the system od, while Open Design is apparently not giving Terminal an OD-backed od command to win on PATH.

The MCP panel is supposed to avoid that by generating an absolute-path launch command instead of relying on bare od, so if the desktop app is still leading you to od mcp install claude on macOS, that’s a bug worth fixing.

Could you paste the text output of type -a od from the screenshot, and also the exact Claude install snippet shown in Settings → MCP server? That will let us separate two cases quickly: (1) the panel is still emitting bare od ... on macOS, or (2) the panel is fine and only the manual command path is broken.

1. od is /usr/bin/od

[lefarcen]

Perfect — od is /usr/bin/od confirms the PATH side of this.

On the repo side, the MCP panel is supposed to avoid PATH completely: /api/mcp/install-info builds the launcher from an absolute runtime path plus an absolute CLI path, not from bare od. So the current split is much narrower now:

• if the command copied from Settings → MCP server works, then the bug is specifically the manual od mcp install claude path for macOS desktop users
• if the copied Settings snippet still fails, then the panel/exported command itself is wrong on macOS desktop

Could you try the exact copied command from the MCP panel once and paste it here as text together with the result? That should be the last piece needed to pin this down.

[BWrong]

It's okay.

[tomkiel]

In fact, the issue is that od is already a built-in Unix command on macOS (/usr/bin/od — octal dump). It's not something you installed, it's part of the system. So when you type od mcp install opencode, the system actually runs the octal dump utility and it tries to open a file called "mcp".
That's why you get that weird No such file or directory error.

Also worth noting: if you installed Open Design via Homebrew (brew install --cask open-design), it only installs the .app bundle. It doesn't expose any CLI to the PATH. Same issue applies. The vela binary is inside the app bundle regardless of how you installed it.

PS: another information, I'm using fish shell as default macOS shell.

Hope this helps :)

[lefarcen]

PR #5219 is now open to tighten the macOS /usr/bin/od collision path for this report.

It updates the README guidance, extends the hosted install.sh shadowed-binary error text for the macOS desktop/Homebrew case, and adds a regression test around that fallback. Keeping this issue open until the PR lands so we can verify the install guidance fully covers the desktop-app path.