The problem
When you fork and contribute to a Beads-using project:.beads/ changes with your personal planning issue. This causes:
- Noise in diffs: Reviewers see unrelated issue database changes
- Merge conflicts: Your issues conflict with upstream issue changes
- Privacy leakage: Your work habits and notes become public
How contributor mode works
Contributor mode automatically detects your role and routes issues accordingly:- Maintainer (SSH access): Issues go to
./.beads/(project database) - Contributor (HTTPS fork): Issues go to
~/.beads-planning/(personal database)
Role detection is automatic based on git remote URL. SSH access implies write permissions (maintainer), HTTPS without credentials implies fork (contributor).
Setting up contributor mode
Run the setup wizard
Navigate to your forked project and run:This:
- Creates
~/.beads-planning/with its own database - Configures
routing.mode=auto - Configures
routing.contributor=~/.beads-planning
Role detection
Beads auto-detects your role using this algorithm:-
Check explicit override:
git config beads.role- If set to
maintainer→ Maintainer - If set to
contributor→ Contributor
- If set to
-
Check push URL:
git remote get-url --push origin- Starts with
git@orssh://→ Maintainer - Contains
@(credentials) → Maintainer - HTTPS without credentials → Contributor
- Starts with
- Default: Contributor (safe fallback)
Explicit role override
For CI environments or shared machines, set explicit role:Using contributor mode
Creating issues
Issues automatically route to planning repo:Viewing issues
By default, commands show issues from both repos:Graduating issues to project repo
When a personal issue becomes a project issue:Configuration
Routing modes
Therouting.mode config controls routing behavior:
auto: Automatic routing based on role detection (recommended)explicit: No routing, use project repo only- (empty): Routing disabled
Planning repo location
Customize where planning issues go:Planning repo prefix
Planning repo can use a different prefix:Troubleshooting
Issues still appearing in project repo
Diagnosis:- Verify
routing.modeisauto - Verify
routing.contributorpoints to planning repo - Check that
BEADS_DIRis NOT set (it overrides routing) - If using SSH URL but want contributor behavior, set
git config beads.role contributor
BEADS_DIR conflicts with routing
Symptom: Warning about BEADS_DIR overriding routing Explanation:BEADS_DIR environment variable takes precedence over routing config.
Solutions:
Planning repo not initialized
Symptom: Error “failed to initialize target repo” Diagnosis:CI environment detection issues
Problem: CI typically uses HTTPS even for maintainers, causing incorrect detection. Solution: Set explicit role in CI config:Contributor vs maintainer comparison
| Aspect | Contributor Mode | Maintainer Mode |
|---|---|---|
| Issues created | ~/.beads-planning/ | ./.beads/ |
| PR pollution | No | Yes (intentional) |
| Sync behavior | Independent | Project repo |
| Role detection | HTTPS fork | SSH or explicit |
| Use case | Personal planning | Project work |
Sync and backup
The planning repo has its own sync configuration:Planning repo does NOT inherit the project repo’s sync configuration. It’s completely independent.
Best practices
For contributors
- ✅ Run
bd init --contributorimmediately after cloning - ✅ Verify routing with a test issue before creating real issues
- ✅ Check
git statusbefore creating PRs to avoid pollution - ✅ Use explicit role override in CI environments
For maintainers
- ✅ Document contributor mode setup in project README
- ✅ Set up
.gitignorefor contributor prefixes (if using prefix-based routing) - ✅ Review PRs for accidental
.beads/pollution - ✅ Use
bd preflightto detect pollution (when available)
See also
- Stealth mode - Local-only Beads without git integration
- Sync and backup - Dolt push/pull workflows
- CLI Reference - Complete command reference