Summary
When beads-ui is running against a project that uses the default embedded Dolt backend, the UI's background polling appears to spawn frequent
bd --sandbox ... subprocesses that acquire the embedded lock often enough to break concurrent bd usage from another tool/process.
I first noticed this because a Pi / Luke Wiggum loop could not advance with luke_wiggum_done, but the root issue seems more general: beads-ui
polling and another bd client contend for the same embedded lock.
Environment
beads-ui: 0.12.0
bd: 1.0.0 (Homebrew)
- macOS:
15.6 (24G84)
- Node:
v25.8.2
- backend mode: embedded Dolt
- project was initialized with normal embedded mode (
bd init, not server mode)
Actual behavior
While beads-ui is open/running, concurrent bd commands from another process intermittently fail with:
failed to open database: embeddeddolt: another process holds the exclusive lock on .../.beads/embeddeddolt; the embedded backend supports only one
writer at a time — use the dolt server backend for concurrent access
What I observed
While the failure was happening, I monitored the lock file and saw two sources acquiring it:
- My active workflow process running commands like:
bd show ... --json
bd children ... --json
bd ready ... --json
- beads-ui running background polling commands like:
bd --sandbox ready --limit 1000 --json
bd --sandbox list --json --tree=false --status in_progress
bd --sandbox list --json --tree=false --status closed --limit 1000
So it looks like beads-ui polling is contending with another active bd client in embedded mode.
Expected behavior
Ideally, running beads-ui should not make embedded-mode bd usage fail for another active client/process.
At minimum, it would help if beads-ui either:
- used a less lock-heavy polling strategy in embedded mode,
- backed off/retried more gracefully,
- or clearly documented that embedded mode is effectively single-client while the UI is open.
Summary
When
beads-uiis running against a project that uses the default embedded Dolt backend, the UI's background polling appears to spawn frequentbd --sandbox ...subprocesses that acquire the embedded lock often enough to break concurrentbdusage from another tool/process.I first noticed this because a Pi / Luke Wiggum loop could not advance with
luke_wiggum_done, but the root issue seems more general:beads-uipolling and another
bdclient contend for the same embedded lock.Environment
beads-ui:0.12.0bd:1.0.0 (Homebrew)15.6 (24G84)v25.8.2bd init, not server mode)Actual behavior
While
beads-uiis open/running, concurrentbdcommands from another process intermittently fail with:What I observed
While the failure was happening, I monitored the lock file and saw two sources acquiring it:
So it looks like beads-ui polling is contending with another active bd client in embedded mode.
Expected behavior
Ideally, running beads-ui should not make embedded-mode bd usage fail for another active client/process.
At minimum, it would help if beads-ui either: