- Added safety check to exportToJSONLWithStore (daemon path)
- Refuses to export 0 issues over non-empty JSONL file
- Added --force flag to override safety check when intentional
- Added test coverage for empty database export protection
- Prevents data loss when daemon has wrong/empty database
Amp-Thread-ID: https://ampcode.com/threads/T-de18e0ad-bd17-46ec-994b-0581e257dcde
Co-authored-by: Amp <amp@ampcode.com>
- Stub out 'bd repos' command with deprecation message
- Remove 140+ lines of global daemon/multi-repo docs from ADVANCED.md
- Add architecture section explaining daemon/MCP/beads roles (LSP model)
- Update AGENTS.md, MCP README, FAQ.md to emphasize per-project daemons
- Update commands/daemon.md and commands/repos.md
Closes#140
Global daemon was removed in v0.16.0 due to cross-project pollution
risks. bd now uses per-project local daemons (one per workspace) for
complete database isolation, following LSP architecture patterns.
Amp-Thread-ID: https://ampcode.com/threads/T-c45147dc-8939-43bf-8fbd-303ed4a8d845
Co-authored-by: Amp <amp@ampcode.com>
- Created test_worktree_separate_dbs.py with 6 comprehensive tests
- Verifies recommended workflow: one .beads database per worktree
- Tests confirm MCP works with BEADS_USE_DAEMON=0 in worktrees
- Validates database isolation, git syncing, and --no-daemon flag
- All tests passing
Addresses GH #119
Amp-Thread-ID: https://ampcode.com/threads/T-57d5c589-0522-4059-8183-2f0f7f1dccba
Co-authored-by: Amp <amp@ampcode.com>
Fixes#114 and #122 by adding --description/-d flag to bd update CLI
and description parameter to MCP update_issue tool.
Changes:
- CLI: Added --description flag to updateCmd
- RPC: Added Description field to UpdateArgs
- Daemon: Updated updatesFromArgs to handle description
- MCP: Added description to update_issue, UpdateIssueParams, and clients
- Storage: description already supported in allowedUpdateFields
Tested in both daemon and direct modes.
Renamed BdDaemonClient.close() cleanup method to cleanup() to eliminate
method name collision with async close(params) method for closing issues.
Root cause: Python method resolution meant the non-async close(self)
cleanup method was shadowing the async close(self, params) method that
closes issues, causing 'takes 1 positional argument but 2 were given'.
Changes:
- bd_daemon_client.py: Renamed close() -> cleanup()
- server.py: Updated cleanup code to call cleanup() instead of close()
- test_lifecycle.py: Updated tests to use cleanup()
All close-related tests pass. Fixes GitHub issue #107.
Tracked in bd-67 (closed).
- Update bd update to use --acceptance instead of --acceptance-criteria
- Update MCP client to use --acceptance flag
- Simplify SKILL.md documentation now that both commands use same flag
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <noreply@anthropic.com>
Add null safety checks in bd_daemon_client.py:
- list_issues(): Return empty array if issues_data is None
- ready(): Return empty array if issues_data is None
- stats(): Use empty dict if stats_data is None
This prevents TypeError crashes when daemon returns None/empty responses.
Amp-Thread-ID: https://ampcode.com/threads/T-072304c3-3a03-4091-92a9-9e16b4538227
Co-authored-by: Amp <amp@ampcode.com>
- Add workspace_root param to all MCP tool signatures (accepted but ignored)
- Fix where_am_i to accept workspace_root
- Fix set_context to always set env vars even when DB not found
- Allows init to work immediately after set_context
- Register atexit handler to close daemon connections
- Add signal handlers for SIGTERM/SIGINT for graceful shutdown
- Implement cleanup() to close all daemon client connections
- Track daemon clients globally for cleanup
- Add close() method to BdDaemonClient (no-op since connections are per-request)
- Register client on first use via _get_client()
- Add comprehensive lifecycle tests
This prevents MCP server processes from accumulating without cleanup.
Each tool invocation will now properly clean up on exit.
Amp-Thread-ID: https://ampcode.com/threads/T-05d76b8e-dac9-472b-bfd0-afe10e3457cd
Co-authored-by: Amp <amp@ampcode.com>
Implements bd-122: Document how to use beads across multiple projects
Added comprehensive multi-repo documentation:
- README.md: Global daemon section with architecture diagram
- AGENTS.md: MCP multi-repo configuration (global daemon + per-project)
- integrations/beads-mcp/README.md: BEADS_WORKING_DIR usage
- Mermaid diagram showing one daemon serving multiple repos
Documentation covers:
- Global daemon (bd daemon --global) for system-wide usage
- Per-project MCP instances with BEADS_WORKING_DIR
- Comparison table (local vs global)
- When to use each approach
- Example workflows for multi-project setups
Benefits of global daemon:
- One daemon process for all repos
- Automatic socket discovery (local -> global fallback)
- Better resource usage
- Per-request context routing to correct database
Amp-Thread-ID: https://ampcode.com/threads/T-ea606216-b886-4af0-bba8-56d000362d01
Co-authored-by: Amp <amp@ampcode.com>
Implements bd-121: Global daemon with system-wide socket
Changes:
- Add --global flag to daemon command
- Use ~/.beads/bd.sock when --global is set
- Skip git repo validation for global daemon
- Update daemon discovery to check ~/.beads/ as fallback
- Both Go CLI and Python MCP client check global socket
- Update all tests to pass global parameter
Benefits:
- Single daemon serves all repos on system
- No per-repo daemon management needed
- Better resource usage for users with many repos
- Automatic fallback when local daemon not running
Usage:
bd daemon --global # Start global daemon
bd daemon --status --global # Check global status
bd daemon --stop --global # Stop global daemon
Related: bd-73 (multi-repo epic)
Amp-Thread-ID: https://ampcode.com/threads/T-ea606216-b886-4af0-bba8-56d000362d01
Co-authored-by: Amp <amp@ampcode.com>
This PR fixes three bugs that prevented the MCP plugin from working:
1. **Fixed parameter name mismatch in tools.py**
- Changed `workspace_root=workspace_root` to `working_dir=workspace_root`
- The `create_bd_client()` function expects `working_dir` parameter,
but tools.py was passing `workspace_root`
- This caused "got an unexpected keyword argument 'workspace_root'" error
2. **Added version check guard for daemon client**
- Added `hasattr(_client, '_check_version')` check before calling
- BdDaemonClient doesn't have `_check_version()` method, only BdCliClient does
- This caused "'BdDaemonClient' object has no attribute '_check_version'" error
3. **Implemented proper daemon socket detection for fallback**
- Added synchronous socket file existence check before creating daemon client
- Walks up directory tree looking for `.beads/bd.sock` file
- Only creates daemon client if socket exists, otherwise falls back to CLI
- Previously, daemon client was created but failed on first method call
- This enables the documented "prefer_daemon with automatic CLI fallback" behavior
**Testing:**
- Verified MCP tools work correctly with single-repo setup
- Confirmed automatic fallback to CLI when daemon isn't running
- Tested on macOS with bd v0.9.9
**Related Issues:**
- Addresses symptoms similar to #65 (Windows BEADS_WORKING_DIR issue)
Since our implementation uses `async` IO for subprocess communication, it's
crucial to utilize the `fastMCP.run_async()` entry-point of FastMCP.
This should fix crashes on Windows.
ref: steveyegge/beads#53
- MCP server now uses daemon client by default with CLI fallback
- Added BEADS_USE_DAEMON environment variable (default: enabled)
- Created multi-repo integration test (all tests pass)
- Updated .gitignore for daemon runtime files
- Added SETUP_DAEMON.md with migration instructions
- Closed bd-105 (investigation complete) and bd-114 (multi-server confusion)
This enables single MCP server to handle multiple repos via daemon
with per-request context routing. No more multiple MCP server configs!
Amp-Thread-ID: https://ampcode.com/threads/T-c222692e-f6ef-4649-9726-db59470b82ef
Co-authored-by: Amp <amp@ampcode.com>
- Added per-request storage routing in daemon server
- Server now supports Cwd field in requests for database discovery
- Tree-walking to find .beads/*.db from any working directory
- Storage caching for performance across requests
- Created Python daemon client (bd_daemon_client.py)
- RPC over Unix socket communication
- Implements full BdClientBase interface
- Auto-discovery of daemon socket from working directory
- Refactored bd_client.py with abstract interface
- BdClientBase abstract class for common interface
- BdCliClient for CLI-based operations (renamed from BdClient)
- create_bd_client() factory with daemon/CLI fallback
- Backwards-compatible BdClient alias
Next: Update MCP server to use daemon client when available
- Remove ~/.beads/default.db fallback from FindDatabasePath()
- Update daemon to error if no database found instead of falling back
- Update main.go to require explicit database initialization
- Add help/version/quickstart to commands that don't need database
- Add MCP client debug logging for database routing
Amp-Thread-ID: https://ampcode.com/threads/T-2b757a14-cf10-400e-a83c-30349182dd82
Co-authored-by: Amp <amp@ampcode.com>
Implements the `bd` reopen command across the entire MCP stack, enabling
agents to reopen closed issues with optional reason tracking for audit
trails. This addresses the need to handle regressions and incorrectly
closed issues without manual `bd` CLI intervention.
The reopen command is more explicit than `bd update --status open` and
emits a dedicated Reopened event in the audit log, making it easier to
track why issues were reopened during analysis.
Changes:
- `models.py`: Add ReopenIssueParams with issue_ids list and optional reason
- `bd_client.py`: Implement reopen() method with JSON response parsing
- `tools.py`: Add beads_reopen_issue() wrapper with Annotated types for MCP
- `server.py`: Register 'reopen' MCP tool with description and parameters
Testing (10 new):
- `test_bd_client.py`: 4 unit tests (mocked subprocess)
- `test_bd_client_integration.py`: 3 integration tests (real `bd` CLI)
- `test_mcp_server_integration.py`: 3 MCP integration tests (FastMCP Client)
- `test_tools.py`: 3 tools wrapper tests (mocked BdClient)
Also updated `README.md`.
1. Fix `test_default_beads_path_auto_detection`
- Changed beads_path to use `Field(default_factory=_default_beads_path)` so the default is evaluated at instance
creation time, not class definition time
- Updated test to mock both `shutil.which` and `os.access`
2. Fix `test_init_creates_beads_directory`
- Fixed test to pass `working_dir=temp_dir` to `BdClient` instead of using `os.chdir()`
- The `_get_working_dir()` method checks `PWD` env var first, which isn't updated by `os.chdir()`
3. Fix minor linting errors reported by `ruff` tool
4. Update `beads` version to `0.9.6` in `uv.lock` file
MCP Server test coverage is now excellent, at 92% overall maintaining our high-standards of production level quality.
```
Name Stmts Miss Cover
------------------------------------------------
src/beads_mcp/__init__.py 1 0 100%
src/beads_mcp/__main__.py 3 3 0%
src/beads_mcp/bd_client.py 214 14 93%
src/beads_mcp/config.py 51 2 96%
src/beads_mcp/models.py 92 1 99%
src/beads_mcp/server.py 58 16 72%
src/beads_mcp/tools.py 59 0 100%
------------------------------------------------
TOTAL 478 36 92%
```
Added a debug tool that reports:
- os.getcwd() value
- PWD environment variable
- BEADS_WORKING_DIR environment variable
- Other relevant environment variables
This will help diagnose where bd commands are running from and whether
Claude Code sets PWD or other variables correctly.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
The MCP server was running bd commands from the plugin installation directory,
causing the database to be created in the wrong place.
Added BEADS_WORKING_DIR config option and modified BdClient to use working
directory for subprocess calls. Falls back to PWD environment variable.
This ensures bd commands run from the user's actual project directory.
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
Prepared the beads-mcp package for publishing to PyPI, simplifying installation
for users who want to use the MCP server with Claude Desktop or other MCP clients.
Changes:
- Added LICENSE file (MIT) to integrations/beads-mcp/
- Updated pyproject.toml with PyPI metadata (license, URLs, classifiers)
- Updated README with simplified installation (uv tool install beads-mcp)
- Created PYPI.md with detailed publishing guide
- Updated examples/claude-desktop-mcp/README to reference the production MCP server
Installation is now simplified from:
git clone && cd && uv sync
to:
uv tool install beads-mcp
Configuration is simplified from multi-line with --directory args to:
"command": "beads-mcp"
Tested build successfully. Package ready for:
- Test PyPI: python -m twine upload --repository testpypi dist/*
- Production PyPI: python -m twine upload dist/*
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add helpful installation instructions when bd CLI is not found,
making it clear that the CLI must be installed separately.
Changes:
- Add BdNotFoundError.installation_message() with clear install steps
- Update all BdNotFoundError raises to use new formatted message
- Improve config error message with installation instructions first
- Update tests to match new error message format
Error message now shows:
- Clear explanation that bd CLI is required
- Installation command with curl one-liner
- Link to GitHub installation docs
- Reminder to restart Claude Code after installation
Test results: 90/91 tests passing (1 unrelated path assertion)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The MCP server was running all bd commands in its own installation directory
(~/.claude/plugins/marketplaces/beads-marketplace/integrations/beads-mcp/)
instead of the user's project directory. This caused databases to be created
in the wrong location.
For example, when working in ~/ai/flutter/wyvern and running `bd init --prefix wy-`,
the database was created at:
~/.claude/plugins/marketplaces/beads-marketplace/integrations/beads-mcp/.beads/wy-.db
Instead of the expected location:
~/ai/flutter/wyvern/.beads/wy-.db
Solution:
- Add `cwd=os.getcwd()` to all asyncio.create_subprocess_exec() calls
- This makes bd commands execute in the current working directory from PWD env var
- Claude Code updates PWD for the MCP server process environment
Impact:
- bd init now creates .beads/ in the correct project directory
- All bd commands (create, list, update, etc.) operate on the correct database
- Multi-project workflows work correctly without manual DB path configuration
Test results: 90/91 tests passing (1 unrelated path assertion failure)
