Bug Description

When starting the MCP server with --project=<project-name>, the background sync and watch service still operate on ALL active projects instead of being constrained to only the specified project.

While MCP tools correctly respect the --project constraint, the background sync infrastructure ignores it completely, leading to unnecessary resource usage and slower startup times when multiple projects are configured.

Steps To Reproduce

1. Configure multiple projects in ~/.basic-memory/config.json:

   {
     "projects": {
       "project-a": "/path/to/project-a",
       "project-b": "/path/to/project-b",
       "project-c": "/path/to/project-c"
     }
   }

2. Start MCP server with project constraint:

   {
     "mcpServers": {
       "basic-memory": {
         "command": "uvx",
         "args": ["basic-memory", "mcp", "--project=project-a"]
       }
     }
   }

3. Check logs (with BASIC_MEMORY_LOG_LEVEL=DEBUG)

4. Observe background sync messages for ALL projects:

   Starting background sync for project: project-a
   Starting background sync for project: project-b
   Starting background sync for project: project-c
   Created 3 background sync tasks
   Starting watch service for all projects
   

Expected Behavior

When --project is specified:

• MCP tools should be constrained to that project ✓ (already works)
• Background sync should ONLY run for that project ✗ (currently broken)
• Watch service should ONLY monitor that project's directory ✗ (currently broken)

The --project flag should provide complete isolation to a single project across all operations.

Actual Behavior

• ✅ MCP tools correctly constrained via BASIC_MEMORY_MCP_PROJECT env var
• ❌ Background sync runs for ALL active projects at startup
• ❌ Watch service monitors ALL project directories for changes

The sync infrastructure completely ignores the project constraint set by the --project flag.

Environment

• OS: macOS (also affects Linux)
• Basic Memory version: 0.16.1 (affects all versions with --project flag)
• Installation method: uvx
• Example config: 12 projects configured, only 1 needed

Code References

The constraint is set:

• src/basic_memory/cli/commands/mcp.py:52 - Sets BASIC_MEMORY_MCP_PROJECT env var
• src/basic_memory/mcp/project_context.py:34-37 - MCP tools check this constraint

But sync ignores it:

• src/basic_memory/services/initialization.py:102 - Calls get_active_projects() without filtering
• src/basic_memory/services/initialization.py:130-132 - Creates sync tasks for ALL projects
• src/basic_memory/sync/watch_service.py:137 - Watch service also loads ALL active projects

Verified with grep: BASIC_MEMORY_MCP_PROJECT is never referenced in initialization.py, watch_service.py, or project_repository.py.

Impact

With many projects configured (e.g., 12 projects):

• 12× the file I/O during startup sync
• 12× the memory usage for watch service
• 12× the file handles being monitored
• Significantly slower startup times
• Wasted CPU cycles on irrelevant projects

User experience impact:

• Violates principle of least surprise - --project should mean "ONLY this project"
• Forces users to choose between:
  • Slow startup with many projects
  • Using skip_initialization_sync=true (loses valuable auto-sync feature)

Workaround

Set skip_initialization_sync: true in config and manually run:

basic-memory sync --project=<project-name>

But this disables the convenient auto-sync feature that makes Basic Memory useful.

Possible Solution

Filter active_projects based on BASIC_MEMORY_MCP_PROJECT in initialize_file_sync():

# In src/basic_memory/services/initialization.py around line 101-102
active_projects = await project_repository.get_active_projects()

# Respect MCP project constraint if set
constrained_project = os.environ.get("BASIC_MEMORY_MCP_PROJECT")
if constrained_project:
    active_projects = [p for p in active_projects if p.name == constrained_project]
    logger.info(f"Background sync constrained to project: {constrained_project}")

This is a single-location fix that would solve the problem for both initial sync and watch service, making the --project flag work consistently across all operations.

Additional Context

This architectural inconsistency means the --project flag only provides partial isolation. MCP tools are constrained but the background infrastructure is not, creating confusion and wasting resources.

Issue drafted by Claude (Anthropic) based on code analysis