[BUG] Cloud API returns `default_project: null` in ProjectList, breaking all CLI project commands

[ryanstraight]

ProjectList validation error: default_project is null in cloud API response

Description

bm project bisync --name foo (and bm project list) fails with:

Error: 1 validation error for ProjectList
default_project
  Input should be a valid string
    For further information visit https://errors.pydantic.dev/2.12/v/string_type

Root Cause

The cloud API endpoint GET /proxy/v2/projects/ returns "default_project": null even when a project has "is_default": true:

{
  "projects": [
    {"name": "main", "is_default": false, ...},
    {"name": "foo", "is_default": true, ...}
  ],
  "default_project": null
}

The ProjectList schema in basic_memory/schemas/project_info.py defines default_project: str (non-optional, no default), so Pydantic validation fails on the null value.

Expected Behavior

default_project should be populated from the project marked is_default: true (i.e., "default_project": "foo"), or the schema should handle null gracefully.

Environment

• Client version: 0.18.5 (pip), CLI binary reports 0.17.9 (stale .local/bin/bm.exe, but same error from both)
• Cloud mode: enabled
• OS: Windows 11
• Python: 3.13

Steps to Reproduce

1. Have cloud mode enabled with a default project configured
2. Run bm project list or bm project bisync --name <project>
3. CLI calls GET /proxy/v2/projects/, receives default_project: null, Pydantic rejects it

Workaround

None found. All CLI commands that call the projects endpoint are broken.

[phernandez]

@claude can you investigate this? write up a root cause and suggest a fix. Don't make a branch/pr

[claude]

Claude finished @phernandez's task in 1m 56s —— View job

---

Investigation: default_project: null in ProjectList

• Read ProjectList schema definition
• Trace how default_project is populated in the API response
• Identify root cause
• Suggest fix

---

Root Cause Analysis

There are actually two separate issues here — one is a schema bug (already fixed in current main), and the other is a deeper logic bug that still exists.

Issue 1: Schema — Optional[str] without a default (partially fixed)

In the current main branch, ProjectList in src/basic_memory/schemas/project_info.py:225-229 reads:

class ProjectList(BaseModel):
    """Response model for listing projects."""

    projects: List[ProjectItem]
    default_project: Optional[str]  # <-- Optional, but no default value

The field is Optional[str] (i.e. str | None), which should accept null from the API without a Pydantic validation error. The reporter's error message ("Input should be a valid string") suggests they may be on an older installed version where the field was declared as plain str. The current main code is safe on this point.

However, the field has no = None default, meaning Pydantic still requires the field to be present in the API response (just allows None as its value). This is fine for now since the cloud API does include the key, just with a null value.

Issue 2: Logic — default_project is always null from the cloud API (the real bug)

This is the deeper problem. In src/basic_memory/api/v2/routers/project_router.py:41-67:

@router.get("/", response_model=ProjectList)
async def list_projects(
    project_service: ProjectServiceDep,
) -> ProjectList:
    projects = await project_service.list_projects()
    default_project = project_service.default_project  # <-- reads ConfigManager!

    project_items = [...]

    return ProjectList(
        projects=project_items,
        default_project=default_project,  # null on cloud server
    )

project_service.default_project (line 83 of project_service.py) delegates to:

@property
def default_project(self) -> Optional[str]:
    return self.config_manager.default_project  # reads local config file!

And ConfigManager.default_project reads default_project from the local YAML config file on disk.

The problem: When this endpoint runs on the cloud server, the server's local ConfigManager doesn't have the user's local config. The database correctly stores is_default=True on one of the projects, but the router ignores that flag and asks ConfigManager instead — which returns None. So the API response always has "default_project": null in cloud mode, even though the database knows which project is default.

The irony: the router already builds project_items with is_default=project.is_default or False correctly set from the database — it just doesn't use that information when populating default_project.

---

Suggested Fix

The fix is minimal and lives entirely in the list_projects router handler. After querying ConfigManager, fall back to deriving default_project from the database's is_default flag if ConfigManager returns None:

@router.get("/", response_model=ProjectList)
async def list_projects(
    project_service: ProjectServiceDep,
) -> ProjectList:
    projects = await project_service.list_projects()
    
    # ConfigManager knows the default in local mode.
    # In cloud mode ConfigManager has no local config, so fall back to
    # the is_default flag stored in the database.
    default_project = project_service.default_project
    if default_project is None:
        default_project = next(
            (p.name for p in projects if p.is_default), None
        )

    project_items = [
        ProjectItem(
            id=project.id,
            external_id=project.external_id,
            name=project.name,
            path=normalize_project_path(project.path),
            is_default=project.is_default or False,
        )
        for project in projects
    ]

    return ProjectList(
        projects=project_items,
        default_project=default_project,
    )

This is safe for both local and cloud modes:

• Local mode: ConfigManager returns the correct name → fallback never triggers.
• Cloud mode: ConfigManager returns None → the fallback scans the project list for is_default=True and returns that project's name. If no project has is_default=True, it correctly stays None.

No schema changes, no new dependencies — just a two-line fallback in the router.

---

Why the CLI breaks on bisync

bm project bisync --name foo internally calls project list (via ProjectClient.list_projects() at mcp/clients/project.py:47-60) which calls ProjectList.model_validate(response.json()). On the reporter's older binary (0.17.9), the schema likely had default_project: str (non-optional), causing Pydantic to reject null. Even on 0.18.5, commands that inspect project_list.default_project and expect a string would fail at runtime.

[phernandez]

shipped: https://github.com/basicmachines-co/basic-memory-cloud/actions/runs/22692304940