Fix startup crash when the OS can't look up the current user's shell - #8496

WHY are these changes introduced?

Fixes the top unhandled CLI startup crash in Observe: shop/issues#75079 — A system error occurred: uv_os_get_passwd returned ENOMEM (not enough memory). P2, 113 events / 53 affected users over 7 days. For these users the CLI does not start at all — no command runs, and no analytics row is emitted.

Also fixes #8497.

WHAT is this pull request doing?

While loading, oclif resolves the active shell from process.env.SHELL ?? os.userInfo().shell. Node's os.userInfo() throws a SystemError whenever the OS can't resolve the current user, and oclif's call is unguarded — so the process dies inside the config.load() we invoke ourselves at packages/cli-kit/src/public/node/cli-launcher.ts:31.

Reported instances are Windows (%APPDATA%\npm global installs), where SHELL is normally unset so the syscall runs on every invocation. Worth noting libuv hardcodes the shell field to NULL on Windows, so that call can never return anything useful there — it can only succeed uselessly or crash.

This sets SHELL before handing off to oclif, but only when the lookup actually fails:

function setShellVariableWhenUserLookupFails(): void {
  if (process.env.SHELL !== undefined) return

  try {
    os.userInfo()
  } catch {
    process.env.SHELL = 'unknown'
  }
}

Why the environment variable rather than a guard. The obvious fix is to override oclif's _shell() on our ShopifyConfig subclass and catch the throw. That works on the pinned 4.8.3 and nothing else: 4.11 drops _shell from Config and moves the logic into a module-level getShell() (lib/util/os.js:37) that a subclass cannot reach. Both versions read the same process.env.SHELL ?? os.userInfo().shell, so seeding the variable is the one lever that covers both — and it does not depend on an undocumented protected member.

That also fixes #8497: the plugins topic resolves to @oclif/core 4.11.14, whose Command.run() re-loads its own Config. A subclass override could never reach it; the environment variable does.

Behaviour on healthy machines is unchanged — the probe only runs when SHELL is unset, and only a throwing lookup writes anything. On a failing machine, config.shell becomes 'unknown', which is what oclif's own fallback branch emits, and feeds one consumer: env_shell in packages/cli-kit/src/private/node/analytics.ts:101. Those users currently send no analytics at all, so this is strictly more data, not less.

Notes for the reviewer

The tests drive the real crash path. They spy on node:os's userInfo — the default import is the same module.exports object oclif's compiled CJS does a property lookup on — and unset SHELL, so config.load() runs oclif's actual detection. Mutation-verified three ways: dropping the call from load(), having the helper swallow the failure without setting SHELL, and setting SHELL unconditionally without probing. Each fails exactly the expected test.

Removal condition. Drop this once @oclif/core guards the call itself. No released version does — it is unguarded in 4.8.3, 4.11.14 and on main. The note lives on the helper.

Not added to environmentIssueMessages. Leaving this class of report unhandled in Observe is what will tell us if the workaround ever stops working or the failure moves to a different frame.

How to test your changes?

pnpm vitest run packages/cli-kit/src/public/node/custom-oclif-loader.test.ts

End to end, with the syscall forced to fail against a built CLI:

cat > /tmp/patch-os.cjs <<'JS'
const os = require('node:os')
os.userInfo = () => { throw new Error('A system error occurred: uv_os_get_passwd returned ENOMEM (not enough memory)') }
JS
env -u SHELL node --require /tmp/patch-os.cjs packages/cli/bin/run.js version
env -u SHELL node --require /tmp/patch-os.cjs packages/cli/bin/run.js plugins

Both crash on main and pass here.

Verified locally: tsc --noEmit -p packages/cli-kit, nx run cli-kit:build, nx run cli:build and bin/run-knip-ci.js all exit 0; eslint clean; full packages/cli-kit suite matches a stashed main baseline exactly (3 pre-existing failures in deprecations.test.ts and node-package-manager.test.ts). Two port-binding tests (tcp.test.ts, graphiql/server.test.ts) flake intermittently under load on my machine — confirmed unrelated by re-running this branch with the two new tests skipped, where they still flake at the same rate.

Measuring impact

• Error monitoring (Observe)

🤖 Generated with Claude Code