Organization secrets
Admin-managed env vars and files shared with every member's agent sessions, and who can read them.
Environment variables and files an admin sets once, for every member.
| Who | Owners and admins can create, update, and delete. Members cannot write them. |
| Plan | No entitlement. |
| Affects | The organization (shared with every member). |
This store ships with cloud workspaces, which are coming soon. Local workspaces don't read it — they use whatever is already in your shell and checkout.
Members cannot read stored values through the settings API. They and their agents can read them once materialized.
Creating and updating#
An admin adds env vars and files from Organization settings. Create, replace, and delete are admin-only. Members see that a secret exists and its name, never its value.
Precedence#
Organization secrets are materialized for each member alongside their other scopes:
- vs personal. Both land in the global environment. On a name collision, the member's personal value takes precedence over the organization value.
- vs repository. Repository secrets are layered into that repo's checkout separately, so they apply on top when an agent works in that repo.
A member gets the org secrets from every organization they belong to, not only the one they are working in. What you store here lands alongside other organizations' secrets.
On a name collision, org values apply in materialization order (last wins), then the member's personal value beats all of them. Scope what you store accordingly.
See Data boundaries for the full scope table.
Storage#
Secret values are encrypted at rest. The settings API returns only metadata, the name and size of each env var and file, never the stored value.
Removing a member does not rotate secrets they could read. Any organization secret that was materialized for a departing member should be treated as exposed to them and rotated. See Members & roles for removing a member.