Skip to content

[BUG] case sensitivity issue with --project #1388

Description

@devlsh

Bug Description

Basic Memory 0.23.2 normalizes a configured project name to lowercase but compares it case-sensitively with the --project constraint used by the MCP indexing and watch services.

For example, a project configured as ExampleProject is stored or resolved as exampleproject, while --project ExampleProject remains mixed-case. The comparison fails, leaving the project without indexing or file-watching tasks even though the service remains healthy.

Steps To Reproduce

  1. Install Basic Memory 0.23.2.
  2. Configure a local project using a mixed-case name such as ExampleProject.
  3. Start the MCP server with bm mcp --project ExampleProject --transport streamable-http.
  4. Add files to the configured project directory.
  5. Inspect the service logs and try to retrieve the files through MCP.

Expected Behavior

The project constraint should resolve consistently regardless of how Basic Memory normalizes the configured project name.

The project should be indexed and watched successfully.

Actual Behavior

The configured project is normalized to exampleproject, but the MCP constraint remains ExampleProject.

The service stays healthy, but it creates no indexing tasks and repeatedly logs:

No projects to watch

Files in the project are therefore unavailable through MCP.

Using the lowercase identifier exampleproject consistently restores indexing and file watching.

Environment

  • OS: Linux container
  • Python version: Unknown; provided by the official container image
  • Basic Memory version: 0.23.2
  • Installation method: Official Basic Memory Docker image
  • Claude Desktop version (if applicable): Not applicable

Additional Context

This appears related to the project-name casing problems previously addressed in #127 and the --project watcher filtering introduced or corrected through #434 and #758.

The current workaround is to use the same lowercase project identifier everywhere, including the project configuration, default project, and --project argument.

Possible Solution

Normalize the --project constraint using the same canonicalization applied to configured and stored project names before comparing them.

Alternatively, resolve the constraint through the project lookup API rather than comparing project-name strings directly.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions