Project access.

Project access decides who can see this project at all. It sits next to the rest of project settings (the gear icon on the right rail) and is visible only to workspace owners and admins.

If you're trying to figure out what each role can do once they're in, see Roles & permissions. This page is about the who.

The default rule #

• Owners and admins of the workspace see every project, always. They don't appear in the access list because there's nothing to add — their access is built in.
• Editors, viewers, and stakeholders see only projects they've been explicitly added to. By default they see no projects at all.

That means for a brand-new workspace, only owners and admins can open any project. Editors won't see anything in their portfolio until you grant them access. This is intentional: you opt people in, not out.

The Access section #

Open project Settings (gear icon, right rail) and scroll to Access. The section has two cards:

• Who can see this project — a short reminder of the rule, so admins coming back to a project they last touched months ago aren't surprised.
• Members (N) — the list of editors, viewers, and stakeholders who currently have access, plus an Add button.

Each row shows name, email, and a role badge — Editor / Viewer / Stakeholder. Owners and admins are not in this list (they have access by role).

Adding a member #

Click Add. The picker is populated with workspace members who don't already have access — i.e., editors, viewers, and stakeholders not yet on the project. You can't type in an external email here; that's the rule the user asked for. To grant access to someone outside your workspace, invite them to the workspace first via Team & invites, then come back here.

Click a name; they're added immediately. The picker closes and the member appears in the list.

If everyone in your workspace already has access, the picker shows "Everyone in the workspace already has access. Invite new members from the Team page."

Removing a member #

Click the × at the right of a row. A confirmation dialog asks "Remove access?" with a one-line explanation: the person will lose access but stays in your workspace, and you can re-add them anytime. Confirm with Remove access.

The list updates and the member's view of the project drops on their next render — if they were viewing the project at the moment, they're redirected to their dashboard with a "That project isn't available" toast.

What happens when access is removed #

A removed member:

• Loses the project from their dashboard, portfolio (if they had it), and command palette.
• Cannot open the project via a shared link — the page redirects to their dashboard.
• Cannot call any project mutation (edit, lock, wish-submit). Server-side rejection is automatic; they don't need to be in the right UI state.
• Keeps any wishes they submitted while they had access — you don't lose triage history.

If they're re-added later, they get the project back. Their old wishes were never deleted.

What gets cleaned up automatically #

When you remove a member entirely from the workspace (Team page), their per-project access is dropped across every project in the same workspace at the same time. If you re-invite them later — even at a different role — they start fresh with no project access until you add them again. This avoids a stale-access footgun where someone returns at a lower role but quietly retains old project rows.

When a project is deleted, all of its access rows go with it. Nothing to clean up.

Sharing vs project access #

These are distinct surfaces:

• Project access (this page) controls workspace members — people with accounts in your SpecGraph workspace.
• Share (the right-rail icon, see Stakeholders) is for external reviewers — partners, customers, regulators — who get a private 14-day token-based portal. They never get a workspace account.

A workspace member added via Project access opens the project at /o/<org>/project/<slug> like everyone else. A stakeholder invited via Share opens it at /p/<token>. Two different doors, two different access models, both gated server-side.

If a workspace viewer is also a project member, they're treated as a viewer everywhere — read-only spec, can submit wishes. The project membership only controls whether they see it; it doesn't change what they can do once inside.

Auditing who has access #

Open the Audit log (admin/owner only — same gear-panel section) for the per-project history of access changes: who was added, who was removed, and when. The audit row records the actor and the target, so you can reconstruct who could see what during any given window.