Add flag to disable project switching

[wtfzambo]

Bug Description

The --project flag seems to be ignored when running certain commands. This is a problem especially when trying to run scoped MCP server with uvx basic-memory --project=... mcp.

Steps To Reproduce

Steps to reproduce the behavior:

1. Install version 0.12.3
2. Run command bm project add work ~/basic-memory/work
3. Use tool/feature bm --project=work project info or bm --project=work sync
4. See that both commands don't apply to the work project, but to the default one, main.

Expected Behavior

--project flag is respected in all commands.

Actual Behavior

--project flag is not respected in all commands, including, apparently, mcp command. Which means to change projects one must do bm project default other_project instead.

Environment

• OS: macOS 15.4.1
• Python version: 3.12.1
• Basic Memory version: 0.12.3
• Installation method: uv
• Claude Desktop version (if applicable): N/A

Additional Context

• Logs or screenshots

[wreed4]

can confirm. This is a pretty big blocker to adopting this tool as it stands.

[phernandez]

Hi @wreed4 and also @wtfzambo, thanks for reporting this. I've been working on a new release that includes this fix. The code is ready, but I'm working on some docs and other info. If you want to upgrade to the latest beta, you can do so.

 uv tool upgrade basic-memory --prerelease=allow

The final v0.13.0 release should be out very shortly. One of the major changes in the new version is that all projects use a single shared db to index data. Consequently, you don't have to set the project at mcp startup, and there are tools available to add/remove/set projects via the LLM. The cli flags are fixed, however.

(basic-memory) ➜  basic-memory git:(main) ✗ bm --project=coffee project info 
╭───────────────── 📊 Basic Memory Project Info ──────────────────╮
│ Project: coffee                                                 │
│ Path: /Users/phernandez/dev/basicmachines/basic-memory/examples │
│ Default Project: main                                           │
│                                                                 │
╰─────────────────────────────────────────────────────────────────╯
         📈 Statistics          
┏━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━┓
┃ Metric               ┃ Count ┃
┡━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━┩
│ Entities             │ 9     │
│ Observations         │ 180   │
│ Relations            │ 38    │
│ Unresolved Relations │ 0     │
│ Isolated Entities    │ 2     │
└──────────────────────┴───────┘

You can see the pre-release release notes here: https://github.com/basicmachines-co/basic-memory/blob/main/RELEASE_NOTES_v0.13.0.md

[wtfzambo]

Awesome @phernandez , thanks for the update!

[wreed4]

awesome @phernandez .

question.. is there a way to disable the switching projects tools? I would like to be able to use different memory bases for different agents, without the ability for memory to leak between agents. Using a project as a security boundary would be a very useful capability. Plus, if the agent can change projects, but it's previously read information from project 1 into its context, there seems like there'd be a pretty high likihood for it to "leak" memories into project 2 . Is there a solution to avoid this behavior?

[phernandez]

@wreed4 Are you asking to disable project switching and cross project tools?

You can disable tools individually in Claude desktop now.

I'd have to add an extra config setting to disable other project args. from the tools. It could be done easily.

[phernandez]

@claude what do you think about disabling project tools?either adding a project setting to

• disable switching projects
• disable cross project operations

[claude]

Claude finished @phernandez's task in 2m 45s —— View job

---

Analysis: Disabling Project Tools

Todo List:

• Examine current MCP project tools implementation
• Analyze security/isolation concerns
• Evaluate configuration options for disabling project tools
• Provide recommendation with pros/cons

Context: @wreed4 raised a valid concern about using projects as security boundaries to prevent memory leakage between different agents. The question is whether to add configuration options to disable project switching and cross-project operations.

---

Current Cross-Project Capabilities

I've analyzed the MCP tools and found two main categories of cross-project functionality:

1. Project Management Tools (project_management.py)

• list_projects() - Lists all available projects
• switch_project(project_name) - Changes active session
• get_current_project() - Shows current project
• set_default_project() - Changes default project globally
• create_project() / delete_project() - Manage projects

2. Content Tools with Cross-Project Access
All content tools accept project: Optional[str] = None parameter:

• write_note(), read_note(), search_notes(), edit_note(), etc.
• When project parameter is provided, operation executes in that project instead of current session
• Tools use get_active_project(project_override) function to determine target project

Security/Isolation Analysis

Current Isolation:

• ✅ Each project has separate database and file system
• ✅ Projects can't accidentally access each other's data without explicit parameters

Current Vulnerabilities:

• ❌ No access control - any user can switch to any project
• ❌ Cross-project operations via optional parameters
• ❌ Global session state affects all subsequent operations
• ❌ Project discovery via list_projects()

Recommendation: Add Configuration Controls

I recommend adding the following configuration options to BasicMemoryConfig:

# Project security settings
disable_project_switching: bool = Field(
    default=False,
    description="Disable tools that allow switching between projects"
)
disable_cross_project_operations: bool = Field(
    default=False, 
    description="Disable project parameter in content tools"
)
restrict_project_discovery: bool = Field(
    default=False,
    description="Prevent listing all available projects"
)

Implementation Strategy:

1. Project Management Tool Filtering - Conditionally register/exclude tools based on config
2. Parameter Validation - Reject project parameters in content tools when disabled
3. Session Lock - Prevent session project changes when switching is disabled

Benefits:

• ✅ Maintains security boundaries for multi-agent scenarios
• ✅ Prevents accidental cross-project contamination
• ✅ Backward compatible (defaults preserve current behavior)
• ✅ Granular control over different aspects of cross-project functionality

Trade-offs:

• ⚠️ Reduces flexibility for legitimate multi-project workflows
• ⚠️ Adds complexity to configuration
• ⚠️ May confuse users who expect full cross-project access

This approach addresses @wreed4's security concerns while maintaining flexibility for users who need cross-project functionality.

Summary: I've analyzed the current cross-project capabilities and recommend adding granular configuration options to disable project switching and cross-project operations when security isolation is needed, while preserving backward compatibility.

---

[bm-claudeai]

✅ Original Bug Fixed in v0.13.0

The original bug reported in this issue (the --project flag being ignored) has been fixed in v0.13.0. The CLI commands now properly respect the --project flag as expected.

You can verify this is working with the current stable release:

uv tool upgrade basic-memory
bm --project=work project info    # Now works correctly

🆕 Feature Request Separated

The discussion in this issue evolved into a feature request for project isolation controls to disable project switching for security purposes. I've created a separate focused issue for this feature:

👉 See #133: Feature: Add configuration options to disable project switching and cross-project operations

The new issue covers:

• Configuration options to disable project switching tools
• Controls for cross-project operations
• Project discovery restrictions
• Security isolation for multi-agent scenarios

Closing This Issue

Since the original bug has been resolved, I'll close this issue. Please continue the feature discussion in issue #133.

Thanks @wtfzambo and @wreed4 for the detailed feedback and helping identify both the bug and the feature need!