Skip to content

Where people and agents ship software together. The open-source git platform for the whole job: issues, agents, checks and deploys to the edge.

61 linesCodeBlameRaw
1---
2title: Permissions
3description: Who may do what in a workspace, in one place, part by part — repositories, teams and chat — and what each setting does.
4---
5
6**Permissions** is where a workspace's owners decide who may do what, part
7by part: `g1t.sh/<workspace>/-/permissions`, under **Workspace → Access**
8in the sidebar. Only owners can open it. Each part of g1t has a card, each
9setting says what it decides, and each card saves on its own with its
10**Save** button; the change holds on everyone's next request and is
11recorded in the [audit log](/guides/audit-log/).
12
13## Code
14
15| Setting | What it decides | Today |
16| --- | --- | --- |
17| **Base permission** | The role every member has on each of the workspace's repositories: **No permission**, **Read**, **Write** or **Admin**. Owners are Admins on all of them, and a role given to someone on one repository adds to this; it never takes away. See [the base permission](/guides/access-and-roles/#the-base-permission). | A new workspace starts at **Read**. |
18| **Members can create public repositories** | Whether any member can create a public repository. | On |
19| **Members can create private repositories** | Whether any member can create a private repository. Whoever creates one is its Admin. | On |
20| **Repository admins can change visibility** | Whether a member with Admin on a repository can make it public or private. | On |
21| **Repository admins can delete and transfer repositories** | Whether a member with Admin on a repository can delete it, or transfer it to a workspace where they can create one. | Off |
22| **Repository admins can add outside collaborators** | Whether a member with Admin on a repository can give a role on it to someone outside the workspace. | On |
23
24The five switches are the workspace's
25[member privileges](/guides/workspaces/#member-privileges), the same ones
26`GET /workspaces/{workspace}` returns by name (`members_can_…`). When one
27is off, only owners can do it; the refusal says so.
28
29## People and teams
30
31| Setting | What it decides | Today |
32| --- | --- | --- |
33| **Who can create teams** | **Any member** with a confirmed email address, or **Owners only**. Whoever creates a team becomes its first maintainer; teams that already exist stay as they are. See [who can create teams](/guides/teams/#who-can-create-teams). | Any member |
34
35## Chat
36
37| Setting | What it decides | Today |
38| --- | --- | --- |
39| **Workspace channels** | Who can create channels anyone in the workspace can join: **Any member** or **Owners only**. Public channels, open to anyone on g1t, are always made by owners. | Any member |
40| **Private channels** | Who can create them: **Any member** or **Owners only**. | Any member |
41
42Renaming and archiving channels, custom emoji and default channels are on
43[Chat settings](/guides/chat/#workspace-chat-settings), under **Workspace →
44Chat**: they are about what a channel's own members may do, not who may do
45what in the workspace.
46
47## Through the API
48
49Every setting is set the way it was before it had this page:
50
51| Setting | Route | MCP |
52| --- | --- | --- |
53| Base permission | [`PUT /workspaces/{workspace}/base_permission`](/reference/api/access/set-base-permission/) | `access` `set_base_permission` |
54| Member privileges, who can create teams | [`PATCH /workspaces/{workspace}`](/reference/api/workspaces/update-workspace/) with `members_can_…` or `team_creation` | `workspace` `update` |
55| Public and private channels | The chat service's workspace settings, as [Chat settings](/guides/chat/#workspace-chat-settings) saves them | |
56
57## Next
58
59- [Access and roles](/guides/access-and-roles/): what each role can do on a repository.
60- [Workspaces](/guides/workspaces/#workspace-mode): every page of Workspace mode.
61- [Audit log](/guides/audit-log/): where each change is recorded.