Quick fixSame lineage, different commands; docs and tutorials mixing them up leads to installing/checking the wrong thing.
oh-my-pi is a hard fork of pi-mono: the code shares a lineage, but the fork publishes under a new name and even renamed the CLI to omp (the npm package @oh-my-pi/pi-coding-agent has "bin": {"omp": "dist/cli.js"}, confirmed by reading it in this marketplace).
The command name is the only reliable identifier after installation — docs may be stale and tutorials may mix things up, but which omp tells you whether it is installed and omp --version tells you the version; the machine does not lie.
So the correct way to "identify the project" is: look at the command name first, then check the repo — do not trust the tutorial title first.
Quick fix
# One-liner: identify the project by command name — the one running omp --version is oh-my-pi
omp --version
What you will run into
While searching/reading material you confuse oh-my-pi with pi-mono, and after install the command name doesn't match (pi vs omp). The commands in tutorials and the command you actually get aren't the same.
Why this happens
| Project | Repo | Command name |
|---|---|---|
| oh-my-pi | can1357/oh-my-pi (hard fork) | omp |
| pi-mono | Original project | pi |
Same lineage, different commands; docs and tutorials mixing them up leads to installing/checking the wrong thing.
Step by step
1. Identify the project by command name — Diagnose
After install, if omp --version runs it's oh-my-pi; pi --version is pi-mono.
2. Identify the repo when reading docs — Diagnose
Repo can1357/oh-my-pi (manifest signature); don't mix in pi-mono tutorials' install commands.
How to confirm it works
Version output and bin name correct (measured output shape):
omp --version → omp/18.0.9 (measured)
package.json bin: {'omp': 'dist/cli.js'} (measured, actually read)Other environments
| Environment | Notes |
|---|---|
| Installed pi-mono | Command name is pi, doesn't match omp tutorials |
| Mixed tutorials | Stick to the can1357/oh-my-pi repo |
| Not measured | Windows/darwin-arm64 binaries, real coding sessions, VS Code extension form |
Symptom
While searching/reading, oh-my-pi gets mixed up with pi-mono; after install the command name does not match (pi vs omp).
Cause
oh-my-pi (can1357/oh-my-pi) is a hard fork whose command is omp; pi-mono is the original project whose command is pi. Same origin, different commands; docs and tutorials mixing them cause wrong installs/searches.
Solution
- Identify the project by command: after install,
omp --versionmeans oh-my-pi;pi --versionmeans pi-mono. - Check docs and confirm the repo: can1357/oh-my-pi (manifest signed); do not mix pi-mono tutorial install commands.
Verification Evidence
- Verified in this marketplace (2026-08-28): the install package
@oh-my-pi/pi-coding-agent's bin name readsomp(package.json bin: {'omp': 'dist/cli.js'}),omp --versionoutputsomp/18.0.9.
Not tested (honestly noted)
- Windows / darwin-arm64 binary extensions (no such assets on Linux/WSL); real coding sessions (need API key); VS Code extension form.
- Environment mechanism discovery: bun 1.4.0's global install dir binds to ~/.bun (setting HOME has no effect), cannot isolate per handbook §5; this card instead validated with a local project install; system global cleaned and restored (see feedback oh-my-pi.@codex-ci.md).
Applicable tools (1)
This problem is linked from the tool pages below — reachable from either side.
oh-my-piSource & evidence
← Coding Agents & Terminal domain ｜ Problem Catalog Experience ｜ Facing another issue? Go to the Helpdesk