Visibility
Series: Tenancy · Members & Roles · Keys · Visibility
Why visibility is a project property, not a member one
Access questions are always asked from the data side: which projects can this member reach? Keeping visibility on the project means a member's view changes the moment a project's flag does — no per-member reconfiguration.
Public projects
Every workspace member can read them. A member with no membership row on a public project gets an effective viewer role — read-only.
Private projects
Only members with a project_members row (plus owner/admin, who bypass visibility) can see them. To everyone else a private project looks like 404 — not 403 — so even existence is hidden.
see_assigned_only
A project-membership flag settable only by admin/owner. A member with see_assigned_only: true on a project sees only tasks assigned to them there.
- It composes with the row's role: writes still require editor/commenter as normal; the flag grants no extra write access.
- It applies equally over REST (
GET /v1/tasks...narrows automatically) and MCP (list_tasks,list_my_tasks).
Public vs private vs assigned-only — when to use which
| Situation | Use |
|---|---|
| Whole workspace openly tracks the roadmap | public project |
| Sub-team's work until ready | private + explicit memberships |
| Outside contractor: contribute but see nothing else | membership + see_assigned_only: true |
| Dashboard app that only surfaces its owner's tasks | app member + assigned-only |
Related: Members & Roles · Guides · Blockers