bm project add --visibility is silently ignored: private and shared both create team-visible projects

[nellins]

Summary

bm project add --cloud --visibility <private|shared> silently creates a project that everyone in the team workspace can see. The flag is validated but never applied.

This is worth treating as more than cosmetic: a user runs --visibility private, gets Project 'x' added successfully, and reasonably believes the project is private. It is not — the whole team can find and open it.

Reproduce

bm project add visibility-check --cloud --workspace "Team Drew" --visibility private
# → Project 'visibility-check' added successfully

Then check it:

bm tool list-projects
# → { "name": "visibility-check", "is_private": false, ... }

And in the app, Settings → Projects:

Visibility Check
Project access: Team
Everyone in Team Drew can find this project.

Same result with --visibility shared (verified separately as vis-shared-check — also is_private: false, also "Project access: Team" in the app).

The flag is being parsed

It isn't ignored at the argument layer — a bogus value is rejected:

bm project add x --cloud --workspace "Team Drew" --visibility notavalue
# → Error: Invalid visibility. Expected one of: workspace, shared, private.

So the CLI accepts private, validates it against the allowed set, and then drops it.

Related

#705 ("CLI: support project visibility when creating projects in a teams workspace") is closed, so this was expected to work. Either the implementation regressed or it never reached the create path.

Two adjacent things worth a look

1. Visibility can't be read back from the CLI at all. Neither bm project list, bm project info, nor bm tool list-projects reports the effective access level (is_private is the closest, and it is false here regardless). There is no way to confirm from the terminal whether a project is private, which is how this went unnoticed.

2. The CLI's vocabulary doesn't match the app's. The CLI and docs describe three tiers — workspace / shared / private. The app's Edit Project Access dialog offers two: Team and Invite-only. There is no "private / just you" option in the UI. If private is not a real tier, the CLI probably shouldn't accept it; if it is, the app should expose it.

Environment

basic-memory 0.23.2, macOS, cloud-routed projects in an organization workspace, Owner role.

[claude]

Claude finished @nellins's task in 38s —— View job

---

Triage

Type: Bug — --visibility is parsed and validated (invalid values are rejected) but the value is never sent through to project creation, so private and shared both silently create workspace-visible (team-visible) projects. Confirmed via bm tool list-projects (is_private: false) and the app's Settings → Projects panel.

Priority: High — this isn't cosmetic. A user passing --visibility private gets a success message and reasonably believes the project is restricted, when in fact the whole team workspace can find and open it. Not Critical only because exposure is bounded to existing team members (not the public), not a full data-loss/external-exposure case.

Component: Cloud (bm project add --cloud, project creation/visibility on the cloud API path). CLI-side flag parsing works correctly; the gap is between validation and the actual create-project call.

Complexity: Medium — needs tracing the CLI project-add flow to where visibility is dropped before reaching the cloud API's POST /api/projects call (likely a missed field on the request payload/DTO), plus a regression test asserting is_private/visibility round-trips correctly for all three tiers.

Related: #705 ("CLI: support project visibility when creating projects in a teams workspace") is the closed issue that specified this behavior — this looks like a regression or incomplete implementation of that work, not a duplicate. No other open issues cover this.

Worth follow-up (not actioned here): the two adjacent gaps the reporter flagged — no CLI/MCP way to read back effective visibility, and the CLI's three-tier vocabulary (workspace/shared/private) vs. the app's two-tier UI (Team/Invite-only) — are real but out of scope for this triage pass and worth a maintainer decision before any fix lands.

Labeled bug + cloud.