Studio.app installs a studio shim at /usr/local/bin/studio and ~/.local/bin/studio, both pointing at Studio.app/Contents/Resources/bin/studio-cli.sh. That shim uses the app's bundled Node and CLI, so it tracks the app automatically.
Installing the CLI from npm instead puts studio in the Node bin directory, which typically sits earlier on PATH (nvm, Homebrew). From then on, studio in a terminal is the npm copy — and the npm copy does not auto-update. It only prints an "Update available" banner.
I hit this with the npm CLI at 1.11.0 while Studio.app had reached 1.21.0 — ten minor versions apart, with no indication that the studio I was typing wasn't the one the app maintains.
Why this matters beyond tidiness: each install bundles its own PHP runtime and its own copy of sqlite-database-integration (~25 sqlite-related paths and ~30 PHP artifacts in each). Both drive the same site directories and the same .ht.sqlite files. A user in this state has two different SQLite drivers writing the same databases, depending on whether they clicked in the app or typed in a terminal.
Reproduce
- Install Studio.app.
npm install -g wp-studiowhich -a studio — the npm path wins:
~/.nvm/versions/node/v24.14.0/bin/studio -> npm wp-studio
~/.local/bin/studio -> Studio.app/.../studio-cli.sh
/usr/local/bin/studio -> Studio.app/.../studio-cli.sh
- Let Studio.app auto-update. The npm copy stays behind indefinitely.
Expected
Either the npm package refuses to shadow an app-managed shim, or studio warns when the CLI and app versions differ, or the Settings → Studio CLI for terminal toggle detects and reports the conflict.
Actual
Silent shadowing and unbounded version drift.
Environment
macOS on Apple M2, Studio.app 1.21.0, wp-studio 1.11.0 from npm, sqlite-database-integration 3.0.0-rc.8.
Studio.app installs a
studioshim at/usr/local/bin/studioand~/.local/bin/studio, both pointing atStudio.app/Contents/Resources/bin/studio-cli.sh. That shim uses the app's bundled Node and CLI, so it tracks the app automatically.Installing the CLI from npm instead puts
studioin the Node bin directory, which typically sits earlier on PATH (nvm, Homebrew). From then on,studioin a terminal is the npm copy — and the npm copy does not auto-update. It only prints an "Update available" banner.I hit this with the npm CLI at 1.11.0 while Studio.app had reached 1.21.0 — ten minor versions apart, with no indication that the
studioI was typing wasn't the one the app maintains.Why this matters beyond tidiness: each install bundles its own PHP runtime and its own copy of
sqlite-database-integration(~25 sqlite-related paths and ~30 PHP artifacts in each). Both drive the same site directories and the same.ht.sqlitefiles. A user in this state has two different SQLite drivers writing the same databases, depending on whether they clicked in the app or typed in a terminal.Reproduce
npm install -g wp-studiowhich -a studio— the npm path wins:Expected
Either the npm package refuses to shadow an app-managed shim, or
studiowarns when the CLI and app versions differ, or the Settings → Studio CLI for terminal toggle detects and reports the conflict.Actual
Silent shadowing and unbounded version drift.
Environment
macOS on Apple M2, Studio.app 1.21.0,
wp-studio1.11.0 from npm,sqlite-database-integration3.0.0-rc.8.