Repository navigation
Conversation
Pi ships only on npm, so Setup could not install it on a computer without Node.js. When the host has no npm, the Pi bridge now offers an Install that runs bb's bundled npm CLI on the runtime the bridge itself runs on (process.execPath, in Node mode under Electron) and installs into <bridge-data>/pi-npm-global. A pi on PATH still wins; otherwise the bb-owned copy is detected by status, the install gate, and launch, and runs on the same runtime with ELECTRON_RUN_AS_NODE removed before Pi starts so it does not leak into agent tool shells. Without a bundled npm (or a runtime older than Node 22.19) the existing missingPrerequisite "nodejs" answer stays. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
When bb installs Pi with its bundled npm on its own runtime, npm runs dependency install scripts with `node` from PATH, which a computer without Node.js doesn't have. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
bb installs Pi with its bundled npm on its own runtime, which on desktop is the Electron app rather than a node on PATH. Dependency install scripts call node and failed. The install now starts through a small bootstrap that writes a node shim (node or node.cmd running bb's runtime with ELECTRON_RUN_AS_NODE=1) into bb's Pi folder, puts it first on PATH, and then runs npm. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
cmd.exe reads batch files in the console's OEM code page and expands % even inside quotes, so a node.cmd shim that embeds bb's runtime path breaks for a Windows profile like C:\Users\José or one containing %. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Batch files are read in the console's OEM code page and expand % inside quotes, so embedding bb's runtime path in node.cmd broke for non-ASCII or %-containing Windows paths. The bootstrap now sets PI_BB_NODE_RUNTIME and both shims (node.cmd and the sh script) read it, so no path is quoted into a script at all. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
brsbl
added a commit
that referenced
this pull request
Oct 21, 2026
Full CI and pushes to main no longer select the first-run job; it runs on PRs that touch agent install or setup paths and on dispatch, and stays continue-on-error until #5948, #5943 and #5429 land. A first turn that times out or ends without the canned reply, or a Pi install without observed dependency lifecycle, now fails instead of being reported as stubbed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
brsbl
marked this pull request as ready for review
October 21, 2026 03:53
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 21, 2026
ymichael
added a commit
that referenced
this pull request
Oct 27, 2026
… defaults (#6194) ## Human comments ## What was wrong bb launches child processes from many places (server, daemon, desktop, launcher, plugins), and each one found executables and built PATH its own way. Under a macOS launchd service or a GUI launch, PATH is minimal, so several things broke: - Plugins could not run `bb` because the CLI's Node was not on PATH (#5807). - Daemon self-update went through a mise npm wrapper that exits 127 after a successful install, so bb treated the update as failed (#6079). - Homebrew upgrades deleted the running Node, and bb kept using the dead path to start workers (#5295). - The Claude Code installation check searched only PATH, so a native install in `~/.local/bin` that was not on PATH was reported missing and bb kept offering to reinstall it (#6284). - Node ignored corporate proxies and OS-trusted certificates because `NODE_USE_ENV_PROXY` and `NODE_USE_SYSTEM_CA` were never set (#5260, #3239). ## What changed - **One resolver:** `HostToolchain` in `packages/process-utils/src/host-toolchain.ts` owns executable lookup, the child PATH and proxy/CA environment, npm selection, and replacement of a deleted Node. - It reads the login-shell PATH, or the user and machine registry PATH on Windows, plus proxy variables from the shell. - It adds the running Node runtime's directory (never the Electron app's) and standard user tool directories (`~/.local/bin`, mise/asdf shims, Volta, and Homebrew on macOS). - Discovery runs in the background and is coalesced. Launches never wait for it. - `ENOENT`, exit 127 and lookup misses start a background refresh. Commands are never replayed. - **Launch helpers:** `spawnHostProcess`, `forkHostProcess`, `execHostFile`, `execHostFileCallback`, `execHostFileBuffer` and `prepareHostPtyCommand` in `host-process.ts` use the resolver. Core call sites across the server, daemon, desktop, CLI, launcher, host-workspace, host-watcher, local-open-targets and the provider kits now use these helpers instead of `node:child_process`. The per-package lookup code is deleted: desktop `desktop-shell-path`, daemon `runtime-shell-env` shell/registry parsing, `selectResolvedExecutable`, and the plugin-local `bb`/`claude` candidate lists. - **Child environments:** - Every child PATH gets the login-shell PATH and the standard tool folders. When the PATH is the one bb started with, the login-shell PATH comes first; when a caller passes a different PATH, the caller's entries stay first. bb never infers that a PATH was meant to be exact. - Scripts that start with `#!/usr/bin/env node` run with the `node` on PATH. - `npm` and `npx` run as found on PATH. Daemon self-update instead runs `npm-cli.js` with the Node installation that owns it (`hostToolchain.npmCli`), which avoids version-manager wrappers. Inside the Electron desktop runtime, bb never substitutes its own runtime for npm. - **Network defaults:** the packaged server/daemon launchers start bb's own Node processes with `--use-system-ca` and `--use-env-proxy` (`@bb/config/node-network`), each only when the runtime accepts it, and bb's forked workers and provider bridge workers inherit them. They are flags rather than exported variables, so terminals, provider CLIs and agent shells keep the user's own Node networking settings. Setting `NODE_USE_SYSTEM_CA=0` or `NODE_USE_ENV_PROXY=0` opts out. `bb-app env set` treats the proxy and CA keys as startup-only. - **Startup:** the daemon and the packaged desktop app wait for discovery at startup. The server starts it in the background. The `bb` CLI never runs it. - **Plugin SDK:** new `@get-bb/plugin-sdk/process` entry point exports `experimental_hostToolchain`, `experimental_spawnHostProcess`, `experimental_forkHostProcess`, `experimental_execHostFile` and `experimental_execHostFileCallback`. Core uses the same implementation. - SDK bumped to 0.6.86. Plugins that import the entry point now require `>=0.6.86`. - `check-plugin-sdk-version.mjs` now watches `src/process.ts`. - Added an entry to `docs/api_to_audit.md` and the Plugin Guide's Provider bridges card. - **Plugins:** MCP, automations, browser automation, GitHub, keep-awake, storage retention (including the external worktree scanner), account pool, and the Claude Code, Codex and Pi providers use the SDK helpers. - **CLI startup:** the `bb` entry imports `@bb/process-utils/host-process` rather than the package barrel, so startup does not load execa. - **Docs:** `docs/configuration.md` covers proxies and certificates and how executable discovery works. - **No wire changes:** `HOST_DAEMON_PROTOCOL_VERSION` is unchanged. Behavior differences from main: - Proxy variables set in the user's login shell now reach child processes when the caller's environment does not set them. - Children receive the caller's PATH extended with the login-shell PATH and the standard tool directories. Not addressed: - Daemon WebSocket connections still ignore the proxy (#4957). - Node releases without built-in environment-proxy support (before 22.21 and 24.5) still connect directly (#3239). - A real corporate proxy or CA deployment has not been verified; the proxy checks used local proxies and mitmproxy. - Codex native installer (#5930) and Pi bundled-runtime install (#5943) remain separate follow-ups. This supersedes #6081, #6083, #5997 and #5948. ## How you verified - New process-utils tests (`host-toolchain.test.ts`, `host-toolchain-windows.test.ts`) cover: - npm install through a mise-style wrapper that exits 127 (#6079) - recovery of a deleted Homebrew Node (#5295) - Claude Code installation status finding a native install outside PATH (#6284; fails on main) - running a `bb` Node script with a minimal service PATH (#5807) - a new command found after the login PATH changes - retaining the last good PATH when discovery fails - bounded probes and no repeated probing of missing commands - non-blocking discovery - caller PATH entries kept first, with the standard folders added after them - caller proxy variables winning over login-shell ones in either case - `#!/usr/bin/env node` scripts not run through the bb runtime - npm paired with the Node that owns it, and the PATH npm used for ordinary launches - a tool in a standard folder found when the caller's PATH lacks it - byte-exact buffered output - no replay after exit 127 - Windows registry PATH expansion and retention - bb-app tests start the server and daemon with real environment proxies and check that `NO_PROXY` bypasses them (#3239), and that explicit opt-outs are kept (#5260). - Reproduced before these fixes, and verified after: - The launcher's `bb --version` took 1.7 s because of a synchronous login-shell probe. It now takes 0.08 s. - A binary git blob came back corrupted (64 bytes in, 121 out). It now comes back byte-exact. - `pnpm exec turbo run typecheck lint --filter='...[origin/main]'` passes. - `pnpm exec turbo run test --filter='[origin/main]'` passes for every changed package except the desktop Electron smoke test below. Under that parallel load, the MCP timeout test and the server builtin hot-reload test missed their timing windows; both pass when run alone. - `check-plugin-sdk-version.mjs` and `oxfmt --check` pass. - Desktop `preload-build` (Electron smoke) times out locally with both this branch's and main's desktop sources, so it is environmental. - Manual checks on real installs: - **Windows 11 ARM64 VM** (bb-app from this branch, started by its sign-in scheduled task): Codex (`codex.exe`), Claude Code (`claude.exe`) and Pi (`pi.cmd`) are detected with their on-disk names. Updating Pi through bb (`bb machine provider-cli install <host> pi --action update`) ran `npm.cmd` in a pty and moved Pi from 1.3.0 to 1.4.0. Signed-in Claude Code and Codex turns run `node`, `npm` and `bb`, and `where.exe` finds node, npm, bb, claude, codex and pi. A bb terminal resolves `codex`, `claude`, `pi`, `node` and `npm` from the registry PATH. - **Packaged macOS desktop app launched with launchd's environment** (`PATH=/usr/bin:/bin:/usr/sbin:/sbin`): the server and daemon receive the login-shell PATH; Codex under `~/.bun/bin` and Pi under nvm are detected; Claude Code, Codex and Pi turns each run `git --version`, `node --version` and `bb --version` successfully. The packaged `bb` CLI runs with `PATH=/usr/bin:/bin` (#5807). This check found that exporting `NODE_USE_*` made `bb --version` inside agent shells print proxy warnings and system-certificate errors; switching to flags fixed it. - **Main vs branch environment diff** (both packaged apps launched with launchd's environment): in a bb terminal, Claude Code and Codex agent shells, and the server, daemon, bridge, Claude and Codex processes, the only differences are the added PATH fallbacks and the network flags on bb's own processes. `node`, `npm`, `git`, `bb`, `codex`, `claude` and `pi` resolve to the same files. This check found the Electron app directory on child PATHs; it is now excluded. - **Proxy:** with `HTTPS_PROXY` in the data directory's `env.json`, the branch routes the server's npm version check and the bridge workers' Claude, Codex, Cursor and OpenCode usage fetches through the proxy; main sends the same requests directly. On Linux, a TLS-intercepting mitmproxy whose CA is only in the system store works with the default flags and fails with `NODE_USE_SYSTEM_CA=0`. This check found that bridge workers lacked the flags; they now inherit them. - **Linux** (Ubuntu 24.04 container, Node from mise only on the login-shell PATH, launched with systemd's default PATH): providers are found through mise shims, a Pi update through bb ran mise's npm, a bb terminal resolves every tool, and a machine running its daemon like the systemd unit self-updated from protocol 255 to a bumped 256 server and reconnected. - **Daemon self-update:** a machine enrolled with the manual installer, running a supervised `--auto-update` daemon under launchd's PATH, updated from protocol 252 to a locally bumped 253 server: it installed the server's package into its private prefix with the Node-owned npm, restarted, and reconnected. The global npm prefix was untouched. Fixes #6079 Fixes #5807 Fixes #5295 Fixes #5260 Fixes #6284 > AGENT GENERATED 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: review <review@local>
Contributor
|
This is an automated message. We have closed this pull request because it has been open for more than two weeks. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Human comments
What was wrong
Pi is published only on npm. A computer without Node.js couldn't install it, so setup could only say "Needs Node.js to install".
What changed
How you verified
%failed before and passes now.Stacked on #5930.
Before:
mainat04bdce811· After: these three PRs combined at33118791d· A fresh computer with no Node.js · Chrome, 1440×900, captured at 2×BB-Thread-ID: thr_k52en5smyw