Workspace visibility

A workspace is born public or born private, chosen once at creation, and the door only swings one way: a public workspace can later be made private, and a private workspace can never be made public. There is no override — not for support, not for an admin, not in SQL (a database trigger refuses the transition with the remedy in the error).

Public means eligible, never readable. A public workspace may list its products on openproduct — a listing exposes the pitch, the maintainers you explicitly publish, and open roles. It does not open the workspace's data: the audit log, runs, agent sessions, secrets, configuration, catalog, member roster and spend stay exactly as private as in a private workspace, served by the same deny-by-default surfaces.

Why the door is one-way

Making an existing workspace public would mean retroactively auditing everything it ever accumulated — an audit trail, agent-session transcripts, secret metadata, run logs, a member roster — and proving none of it reaches the public surface. A workspace that was never private has nothing to redact, so the honest moment to decide is creation, before there is any history to audit. An "exception process" for the reverse direction is how such rules erode, so none exists.

The account opt-in

Public workspaces are off until an account owner or admin enables them: Settings → Account → Public workspaces on the account root. The setting gates creation only — turning it off later privatises nothing (that would be a silent mass-unpublish); existing public workspaces are narrowed one at a time by their own owners.

A first workspace can never be born public: it is the account being created, so there is nothing to have opted in yet. Create it private, enable public workspaces on the account, then create a public workspace under it.

What being public changes

Concern	Public workspace
Members	Free. Members and pending invitations never count toward limit.members — approving contributor four hundred is as unremarkable as approving contributor four. The seat gate is skipped (and logs the skip); narrowing to private brings the seats back.
Compute	Metered normally. Nothing about being public makes a run free — the credit wallet and budget envelopes gate the dispatch door exactly as on a private workspace, billed to the workspace's own account.
Concurrency	Hard ceiling of 5 in-flight agent sessions, independent of plan, at both dispatch paths (tasks and routines). The refusal names the ceiling. This is the abuse bound that makes free membership safe to offer.
Listings	Eligible. Publishing a listing still takes everything it always took: a linked public repository, a pitch, and a one-time admin review. A private workspace sees workspace_private as the first publish blocker.
Narrowing	Owner-only. Making a public workspace private unlists every listing (within the cache TTL) and cannot be reversed.

"I built it private and now I want to list it"

You don't flip the workspace — you can't. The path is:

1. An account owner enables public workspaces (Settings → Account).
2. Create a new public workspace under the account.
3. Link the same repository to a project there — a repository can be linked from more than one workspace — and publish the listing from the public workspace.

History does not travel, deliberately: the private workspace keeps its audit trail, runs and sessions, and the public one starts clean — which is the entire point of the rule.

API

Method	Path	Notes
POST	/v1/organizations	visibility: "public" — refused with public_requires_account (first workspace) or public_not_enabled (account has not opted in)
PATCH	/v1/organizations/{ref}	visibility: "private" narrows (owner-only, its own request — not combinable with a rename); "public" is refused with visibility_widening_refused. `allowPublicWorkspaces: true
—	events	organization.visibility_narrowed, organization.public_workspaces_setting_changed — both audited