[ymichael]

Summary

• strip per-thread context only from long-lived production server and daemon environments while preserving it for the bundled bb CLI
• make the host daemon derive its shared thread-storage root from its data directory unless an explicit programmatic override is supplied
• add production-launcher, CLI-context, and host-daemon regressions for an inherited parent BB_THREAD_STORAGE

Confirmed mechanism

Commit 1688734bb1bfdb26a844f868bf7f3d07ab9b0c2b made the server derive per-host thread paths from the host session data directory instead of ambient BB_THREAD_STORAGE, but the daemon still adopted ambient BB_THREAD_STORAGE as its global root. When bb starts with a parent thread's environment, the daemon root narrows to the parent thread directory while the server sends a sibling worker path. requireConfinedPath correctly rejects that sibling as escaping the narrowed root.

The standalone QA launcher and dev launcher already strip this context. The production launcher did not. This PR fixes both layers: production child processes are sanitized and the daemon no longer treats ambient per-thread context as global configuration.

Reproduction

I ran the issue's exact pathprobe workflow with Claude Haiku from a real bb-managed worktree:

Build and launch	Result
Signed Desktop 0.37.0 artifact, clean environment	succeeded: {"r":"ok"}
Signed Desktop auto-update 0.36.0 → 0.37.0, same isolated data/profile and managed-worktree origin	succeeded before and after: {"r":"ok"}
npm bb-app@0.37.0, clean environment	succeeded: {"r":"ok"}
npm bb-app@0.36.0, clean environment	succeeded: {"r":"ok"}
Signed Desktop 0.37.0 launched by the reporter's agent via open -a with inherited thread context	failed with the exact Thread storage path escapes the storage root log
npm bb-app@0.37.0 with the same inherited context	failed identically
npm bb-app@0.36.0 with the same inherited context	failed identically
This PR with the same inherited context and existing 0.37 data	succeeded: {"r":"ok"}

The reporter subsequently reconstructed the timeline and confirmed both the failing and passing runs were on 0.37.0. The failing instance was installed and launched with open -a by a detached script started from a bb agent shell, which propagated that thread's environment into Desktop. The passing instance was cleanly relaunched by the built-in updater. This matches the controlled matrix exactly: the split is contaminated agent launch versus clean updater launch, not 0.36.0 versus 0.37.0.

The divergence was introduced by commit 1688734bb1bfdb26a844f868bf7f3d07ab9b0c2b (Inject global app skills into agent runtimes): the server began deriving storage from the host session data directory while the daemon still adopted ambient BB_THREAD_STORAGE. The confinement check predates that commit. No commit in the 0.36.0..0.37.0 range introduced this failure.

Users do not need to roll back: fully quit the contaminated Desktop instance and relaunch it from Finder, Dock, the updater, or another environment without thread-scoped BB_* variables.

Verification

• pnpm exec turbo run test --filter=@bb/host-daemon --force — 537 passed
• pnpm exec turbo run test --filter=bb-app --filter=@bb/config --force — 171 passed
• pnpm exec turbo run typecheck --filter=@bb/host-daemon --filter=bb-app --filter=@bb/config
• the host-daemon regression fails with the ambient lookup restored, receiving the parent thread path instead of <dataDir>/thread-storage
• the production launcher test executes the bundled CLI child path and verifies that CLI thread context is retained while server/daemon context is removed

No HOST_DAEMON_PROTOCOL_VERSION bump is needed because no server/daemon message or RPC contract changes.

Fixes #1366

AGENT GENERATED: by GPT-5.6

[SawyerHood]

🚨 SLOP COP 🚨 · review

I am the SlopCop. I am now reviewing this pull request for security, code quality, performance, architecture, and test coverage.

[SawyerHood]

🚨 SLOP COP 🚨 · review

ELI5: A parent agent gave the BB daemon one thread folder as if it were the folder for all threads. This change stops that mistake.

I found one blocking regression.

The production launcher removes BB_THREAD_ID and BB_THREAD_STORAGE from runtime.env. The same environment then starts the bundled bb CLI. This breaks commands that use the current thread, including bb thread show --self and bb thread spawn --parent-self.

I reproduced the problem. The normal bb status command found this thread. The packaged launcher path reported Thread: (not set). The packaged bb thread show --self path failed because BB_THREAD_ID was absent.

Please keep thread context for the CLI path. Remove it only from long-lived server and daemon environments. Add a launcher test that starts the CLI child and verifies a context command.

The security review found no security defect. The performance review found only small extra environment copies. No daemon protocol version change is necessary because the wire contract does not change.

The architecture scan found similar root logic in the server and daemon. The active server path already forces data-directory root selection with an empty environment. The remaining ambient server fallback looks stale, but it does not block this fix.

A browser test does not apply because this change has no browser route. Launcher, daemon, and focused QA tests provide the correct coverage.

Checks passed:

• 708 affected package tests
• 12 focused QA tests
• Turbo type checks for @bb/config, bb-app, and @bb/host-daemon
• The bb-app Turbo build
• git diff --check

I posted this as a comment-only review. I did not approve the pull request or request changes through GitHub.

[ymichael]

Nested dev-server QA completed against the reporter-confirmed activation path.

1. Started this branch through scripts/bb-dev-app.
2. Used that dev server CLI to create a project for this checkout and spawn real agent thread thr_f5nmiydynp.
3. From that thread Bash environment, verified BB_THREAD_ID, BB_THREAD_STORAGE, BB_ENVIRONMENT_ID, BB_PROJECT_ID, BB_SERVER_URL, BB_HOST_DAEMON_PORT, and BB_CLI were present.
4. The agent launched an isolated production bb-app stack from this PR without unsetting any inherited variables.
5. In that inner stack, created origin thread thr_cis896kbsq in the same worktree and ran the issue exact pathprobe.
6. Relaunched the exact same inner data, project, origin thread, environment, workflow source, provider, and model through unpatched npm bb-app@0.37.0 from the same outer agent shell.

A/B result:

• PR run wfr_851dd88f-17f6-4b8d-9168-ff9aa952f03c: succeeded; call succeeded; worker thr_ec8pzpr7qm; result {"r":"ok"}.
• Unpatched 0.37.0 run wfr_f9f8292b-c8e3-4c2d-af54-52dc936145b5: failed; call failed; worker thr_hyujbx3v8m; error Command thread.start failed.

The unpatched server log contains the issue exact error and stack: ApiError status 502, code invalid_path, message Thread storage path escapes the storage root, logged as Live thread start command failed through callHostOnlineRpcWithRetry -> runLiveHostCommand.

Process inspection showed the outer agent variables in the unpatched server and daemon children. In the PR stack, BB_THREAD_ID, BB_THREAD_STORAGE, and BB_ENVIRONMENT_ID were absent from the server/daemon children while the launcher retained them for its CLI context.

All isolated and dev processes were stopped after capture.