Repository navigation
Agent-launched Desktop inherits parent thread storage root, breaking workflow workers #1366
Description
What happens
On desktop 0.37.0, every workflow run dies within ~1s. The run-level error is:
Workflow worker failed before attachment completed
The real cause is in ~/.bb/logs/server*.log, logged as Live thread start command failed:
{"err":{"type":"ApiError","message":"Thread storage path escapes the storage root",
"status":502,"body":{"code":"invalid_path","retryable":false}},
"threadId":"thr_hmtzy76yiu","msg":"Live thread start command failed"}Stack: callHostOnlineRpcWithRetry → runLiveHostCommand (server/dist/start-server.js).
Not workflow-specific to one script
Minimal repro — this two-line workflow fails on 0.37.0 and succeeds on 0.36.0:
export const meta = { name: "pathprobe", description: "can a worker thread start", phases: [{ title: "Probe" }] };
phase("Probe");
const r = await agent("Reply with exactly the word: ok", {
label: "probe", phase: "Probe",
provider: "claude-code", model: "claude-haiku-4-5-20251001", reasoningLevel: "low",
});
return { r };- 0.37.0 →
failed, 1 call failed, error as above (reproduced on two different workflows, 3 runs). - 0.36.0 (same machine, same data dir, rolled straight back) →
succeeded,{"r":"ok"}.
Environment
- macOS 26 (Darwin 25.5.0), arm64, desktop build
bb-0.37.0-arm64.zipfrom thedesktop-latestfeed (sha512 matcheslatest-mac.yml). - Data dir
~/.bb— a real directory, not a symlink;realpath(~/.bb/thread-storage)equals itself, so there is no local path indirection to blame. - The origin thread runs in a bb-managed worktree environment (
~/.bb/worktrees/<env>/<repo>), if that is what the storage-root check is resolving against.
Impact
Everything built on workflows stops on 0.37.0 — for me that is the nightly memory-curation and standup automations plus a scheduled research workflow, all of which fail silently apart from a notification. I rolled back to 0.36.0 to keep them running.
Metadata
Metadata
Assignees
Labels
No labels
Activity
ymichael commentedon Aug 12, 2026
I reproduced the exact failure, but found an important version-specific wrinkle.
Using the signed 0.37.0 Desktop artifact and the issue's exact
pathprobeworkflow from a bb-managed worktree:{"r":"ok"}BB_THREAD_STORAGEinherited from the origin thread: fails with the exact loggedThread storage path escapes the storage rootI also tested the npm production launcher for both releases:
So the inherited-root mechanism is confirmed, but it is a latent defect present in both versions; the relevant root-resolution code is unchanged between the tags. The remaining question is why the 0.37.0 daemon inherited thread context while the rollback launch did not.
Could you share how each build was launched: auto-update, Finder,
open, or executing the app binary from a terminal/agent? In particular, was 0.37.0 installed or started by a bb agent or from a bb thread terminal? That distinction would explain the observed 0.37-fail/0.36-pass split and let us pin down the activation path rather than infer it.ymichael commentedon Aug 12, 2026
Auto-update follow-up: I have now tested the real signed Desktop update path end to end.
I also inspected the Desktop, bridge, server, and daemon process environments on both sides of the update. None contained BB_THREAD_STORAGE, BB_THREAD_ID, BB_ENVIRONMENT_ID, or BB_PROJECT_ID.
Conclusion: a clean signed 0.36.0 -> 0.37.0 Desktop auto-update does not itself introduce the inherited thread context and does not reproduce #1366. The inherited-root failure remains real: deliberately launching either 0.36.0 or 0.37.0 from a parent agent environment reproduces the exact error, and PR #1368 prevents that failure. But this auto-update result means we still have not identified what made the reporter launch contaminated only on 0.37.0; the root-resolution defect predates both releases.
MGrin commentedon Aug 12, 2026
You're right to keep pulling on the launch path. I went back through this machine's logs and the version claim in my report is wrong: both the failing and the passing run were on 0.37.0. 0.36.0 was never actually exercised.
The upgrade was performed by an agent thread of mine running in a bb-managed worktree environment, not by me at the keyboard. It wrote a detached install script and started it with
nohup … & disownfrom its Bash tool, so the script inherited that thread's env (BB_THREAD_ID,BB_THREAD_STORAGE,BB_ENVIRONMENT_ID,BB_PROJECT_ID). Times UTC:dittos the signed 0.37.0 bundle into/Applications/bb.app, launches it withopen -a /Applications/bb.app. Desktop 0.37.0 up at 02:26:00 (host daemon protocol 104).Thread storage path escapes the storage rootfailures (thr_hmtzy76yiu,thr_u64x78s726). The only two occurrences in any of my server logs.open -a, again from the inherited env. 0.36.0 comes up at 02:33:23 (daemon protocol 82). No workflow was ever run against it — that daemon session lasted about a second.~/Library/Caches/@bbdesktop-updater/pending/bb-0.37.0-arm64.zip) and applies it on quit.bb --versionprinted0.37.0and thepathprobeworkflow succeeded with{"r":"ok"}. The agent logged that as "0.36.0 passes"; it was 0.37.0, relaunched by the updater. A 25-worker workflow ran clean immediately after, still on 0.37.0.So the split is not 0.37 vs 0.36. It is agent-launched via
open -avs updater-relaunched, which lines up with both of your results.Mechanism, verified on this machine just now: on macOS 26,
open -apropagates the calling shell's environment to a freshly launched app. I built a minimal ad-hoc-signed.appthat writes its environment to a file and launched it withopen -afrom a bb agent's Bash tool; it receivedBB_THREAD_ID,BB_THREAD_STORAGE,BB_ENVIRONMENT_ID,BB_PROJECT_ID,BB_SERVER_URL,BB_HOST_DAEMON_PORTandBB_CLI. That is the activation path — the Desktop app inherited a thread's storage root, the daemon resolved worker storage against it, and every worker start failed. Your deliberate repro and this accident are the same thing.For completeness: the bridge process running here now (0.37.0, launched normally) has no
BB_*in its environment exceptBB_APP_SURFACE=desktop, and workflows have been fine since 02:37.Apologies for the misleading version framing — "rolled straight back" was the agent's inference, and the updater had quietly restored 0.37.0 four minutes before the passing probe. The defect #1368 fixes is real; the version correlation isn't. Retitle or fold it into the inherited-root fix as you see fit.
One side observation from the same timeline: the rollback to 0.36.0 was auto-updated back to 0.37.0 within ~4 minutes without a prompt, which is what made the version comparison impossible to run in the first place.
[-]0.37.0: every workflow worker fails to start — "Thread storage path escapes the storage root"[/-][+]Agent-launched Desktop inherits parent thread storage root, breaking workflow workers[/+]ymichael commentedon Aug 12, 2026
Thank you for reconstructing the timeline and verifying the macOS activation behavior. That closes the causal gap and matches the controlled matrix:
I retitled the issue and updated PR #1368 accordingly. The historical introducing commit is 1688734 (Inject global app skills into agent runtimes): it made the server derive thread storage from the host session data directory while the daemon continued adopting ambient BB_THREAD_STORAGE. The confinement check predates that change; the suspected 0.37-range commits are not causal.
Workaround for 0.37.0: fully quit the contaminated Desktop instance and relaunch it from Finder, Dock, the updater, or another environment without the thread-scoped BB variables. Rolling back is unnecessary. PR #1368 hardens both sides by sanitizing long-lived production child environments and removing the daemon ambient fallback.
Fix inherited thread storage root (#1368)