claude-use 0.2.9 → 0.2.10

package/README.md

@@ -49,7 +49,7 @@ scoop bucket add claude-use https://github.com/ExaDev/scoop-claude-use
 scoop install claude-use
 ```
 
-Every channel installs `claude-use` alone — none of them install a `claude` command; `claude-use shim enable` is the one explicit action that does, on any of them. The GitHub Release binary, Homebrew, and Scoop all ship the self-contained Node SEA build (no Node.js installation required) — macOS arm64, both Linux architectures, and both Windows architectures are all targets Node core itself tests and verifies `--build-sea` against upstream; the GitHub Release binary for macOS x64 is published best-effort, since Node core does not test or verify single-executable-application support on that target and the resulting binary genuinely crashes there (see [Build (Node SEA)](#build-node-sea) below). **Homebrew on macOS x64 is the one exception**: rather than installing that broken binary, the formula depends on Homebrew's own `node` and installs the same plain bundle the npm channel publishes — a real, working `claude-use`, not a best-effort one. npm ships the plain bundle everywhere, running under whatever Node ≥ 22.12 you already have.
+Every channel installs `claude-use` alone — none of them install a `claude` command; `claude-use shim enable` is the one explicit action that does, on any of them. The GitHub Release binary and Scoop ship the self-contained Node SEA build (no Node.js installation required) — macOS arm64, both Linux architectures, and both Windows architectures are all targets Node core itself tests and verifies `--build-sea` against upstream; the raw GitHub Release binary for macOS x64 is published best-effort, since Node core does not test or verify single-executable-application support on that target and the resulting binary genuinely crashes there (see [Build (Node SEA)](#build-node-sea) below). **Homebrew and `install.sh` both work around this on macOS x64 specifically**: rather than installing that broken binary, they depend on (or check for) Node and install the same plain bundle the npm channel publishes — a real, working `claude-use`, not a best-effort one. npm ships the plain bundle everywhere, running under whatever Node ≥ 22.12 you already have.
 
 ## Quick start
 
@@ -529,7 +529,9 @@ macOS SEA support is tested and verified upstream on **arm64 only** — x64 is e
 
 **Root cause, confirmed rather than assumed.** Reproduced locally under Rosetta with 100% fidelity to CI: `lldb` shows `EXC_BAD_ACCESS` inside `__cxx_global_var_init`, invoked by `dyld` while running C++ static initializers — before `main()` ever executes, with `rdi` (the faulting access) holding the literal value `0x2`. A trivial one-line `console.log(...)` script built through the exact same `--build-sea` + ad-hoc-codesign steps crashes identically, which rules out anything in claude-use's own bundle, build script, or code — this is `--build-sea` itself misbehaving on x64 macOS. This is a known, tracked, and deliberately unfixed upstream limitation: [nodejs/node#62893](https://github.com/nodejs/node/issues/62893) reproduces the identical crash and was closed as documentation-only ([nodejs/node#63181](https://github.com/nodejs/node/pull/63181)), with a Node core maintainer stating SEA on x64 macOS "is not supported and skipped in the tests... until someone volunteers to implement support for it." The deeper investigation thread ([nodejs/node#59553](https://github.com/nodejs/node/issues/59553)) floats an unconfirmed theory — that `postject`'s LIEF-based Mach-O binary injection corrupts the executable such that `dyld` misidentifies a segment as an oversized (>4GB) thread-local-storage region — but that thread closed stale, unfixed, with the same maintainer concluding it's "unlikely that anyone would invest time in fixing it for macOS" given x64 macOS's Tier 2 deprioritisation upstream. There is no available workaround (no alternate `codesign` invocation, `sea-config.json` option, or Node flag) — the fault is inside `--build-sea`'s own binary-injection step, before any code this project controls runs at all.
 
-**Homebrew works around this by not using the SEA binary at all on this one architecture.** Since there's no fix available for the binary itself, `update-tap`'s generated formula gives macOS x64 a genuinely different install path: `on_intel do ... depends_on "node" end` nested under `on_macos`, pointing at the npm registry tarball (`https://registry.npmjs.org/claude-use/-/claude-use-<version>.tgz`) instead of the GitHub Release SEA asset, and `def install` branches on `OS.mac? && Hardware::CPU.intel?` to run `system "npm", "install", *std_npm_args` (Homebrew's own documented Node-formula pattern — see the [Formula Cookbook](https://docs.brew.sh/Formula-Cookbook) and [Language-Specific Formulae](https://docs.brew.sh/Language-Specific-Formulae) docs) followed by `bin.install_symlink libexec.glob("bin/*")`, rather than downloading and `bin.install`-ing a binary. `depends_on "node"` inside an `on_intel` block is legal precisely because it's a metadata declaration Homebrew resolves at build-spec time, not runtime logic — the actual branch deciding *which* install steps run lives in `def install` using `OS.mac?`/`Hardware::CPU.intel?`, exactly as the Cookbook prescribes. This means `brew install ExaDev/claude-use/claude-use` gives macOS x64 users a genuinely working `claude-use` (the same code the npm channel already publishes and verifies), unlike the raw GitHub Release binary and `install.sh` on that architecture, which still ship the best-effort, currently-broken SEA binary described above.
+**Homebrew works around this by not using the SEA binary at all on this one architecture.** Since there's no fix available for the binary itself, `update-tap`'s generated formula gives macOS x64 a genuinely different install path: `on_intel do ... depends_on "node" end` nested under `on_macos`, pointing at the npm registry tarball (`https://registry.npmjs.org/claude-use/-/claude-use-<version>.tgz`) instead of the GitHub Release SEA asset, and `def install` branches on `OS.mac? && Hardware::CPU.intel?` to run `system "npm", "install", *std_npm_args` (Homebrew's own documented Node-formula pattern — see the [Formula Cookbook](https://docs.brew.sh/Formula-Cookbook) and [Language-Specific Formulae](https://docs.brew.sh/Language-Specific-Formulae) docs) followed by `bin.install_symlink libexec.glob("bin/*")`, rather than downloading and `bin.install`-ing a binary. `depends_on "node"` inside an `on_intel` block is legal precisely because it's a metadata declaration Homebrew resolves at build-spec time, not runtime logic — the actual branch deciding *which* install steps run lives in `def install` using `OS.mac?`/`Hardware::CPU.intel?`, exactly as the Cookbook prescribes. This means `brew install ExaDev/claude-use/claude-use` gives macOS x64 users a genuinely working `claude-use` (the same code the npm channel already publishes and verifies), unlike the raw GitHub Release binary on that architecture, which still ships the best-effort, currently-broken SEA binary described above.
+
+**`install.sh` takes the same workaround**, since it can express the equivalent of `depends_on "node"` itself (a POSIX shell script, unlike a Homebrew formula, has no package manager underneath it to declare dependencies to): on macOS x64 specifically, it checks for `npm` on `PATH` before anything else, and — if present — installs into a scratch npm prefix and copies the resulting `bin/claude-use` script into place, exactly matching where the binary-download path would have put it, rather than downloading the broken SEA asset at all. If `npm` isn't available, it exits with a clear error pointing at installing Node.js first or using Homebrew instead (which resolves this automatically via its own `node` dependency), rather than silently installing something broken.
 
 Windows and Linux carry no such carve-out — Node's own SEA documentation tests both regularly across every architecture it supports on those platforms (x64 and arm64 alike), so CI builds and verifies all four of those binaries as fully supported release artefacts, same as macOS arm64.
 

package/dist/cli.cjs

@@ -221857,7 +221857,7 @@ var categories_default_default = {
 // package.json
 var package_default = {
   name: "claude-use",
-  version: "0.2.9",
+  version: "0.2.10",
   description: "A profile manager and launcher for Claude Code that lets one person run multiple logins from one machine while controlling what gets shared between them.",
   license: "Apache-2.0",
   author: "Joseph Mearman <joseph@mearman.co.uk>",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-use",
-  "version": "0.2.9",
+  "version": "0.2.10",
   "description": "A profile manager and launcher for Claude Code that lets one person run multiple logins from one machine while controlling what gets shared between them.",
   "license": "Apache-2.0",
   "author": "Joseph Mearman <joseph@mearman.co.uk>",