| 1 | --- |
| 2 | title: Access and roles |
| 3 | description: The five repository roles and what each can do, the base permission members get, the Admin role a repository's creator gets, security managers, roles through teams, outside collaborators and invitations, who may manage deploy keys, and what agents may do on a person's behalf. |
| 4 | --- |
| 5 | |
| 6 | Everyone who can work in a repository has a role on it. The role says what |
| 7 | they can do there, from reading it to managing who else has access. A |
| 8 | workspace gives its members a role on every one of its repositories, a |
| 9 | repository can give anyone a role of their own: a member who needs more |
| 10 | there, or someone outside the workspace, and it can give a |
| 11 | [team](/guides/teams/) a role that everyone in the team has. |
| 12 | |
| 13 | ## The roles |
| 14 | |
| 15 | | Role | For | |
| 16 | | --- | --- | |
| 17 | | **Read** | Read and clone; open issues and pull requests, and comment. | |
| 18 | | **Triage** | Read, and manage issues and pull requests: apply labels and milestones, assign, close. | |
| 19 | | **Write** | Triage, and push, merge, manage labels and milestones, see security alerts, and put agents to work. | |
| 20 | | **Maintain** | Write, and manage the repository's settings and topics. | |
| 21 | | **Admin** | Everything: branch protection and rulesets, webhooks, secrets, deployments, security settings, who has access, and the repository's name, visibility and archiving. | |
| 22 | |
| 23 | Each role has everything the one above it has. |
| 24 | |
| 25 | ## What each role can do |
| 26 | |
| 27 | | | Read | Triage | Write | Maintain | Admin | |
| 28 | | --- | --- | --- | --- | --- | --- | |
| 29 | | See code, issues and pull requests; clone and fetch | Yes | Yes | Yes | Yes | Yes | |
| 30 | | Open issues and pull requests, and comment | Yes | Yes | Yes | Yes | Yes | |
| 31 | | Apply labels and milestones; assign, close and reopen issues and pull requests | | Yes | Yes | Yes | Yes | |
| 32 | | Push to branches that are not protected | | | Yes | Yes | Yes | |
| 33 | | Merge pull requests and use the merge queue | | | Yes | Yes | Yes | |
| 34 | | Create, edit and delete labels and milestones | | | Yes | Yes | Yes | |
| 35 | | See and dismiss security alerts | | | Yes | Yes | Yes | |
| 36 | | Assign agents and start runs, plans and workflows | | | Yes | Yes | Yes | |
| 37 | | Change the description, topics, and pull request and agent settings | | | | Yes | Yes | |
| 38 | | Change branch protection, rulesets and guardrails | | | | | Yes | |
| 39 | | Change security settings, custom patterns and bypass reviews | | | | | Yes | |
| 40 | | Manage webhooks, secrets, variables, deployments and domains | | | | | Yes | |
| 41 | | Manage who has access, invitations and deploy keys | | | | | Yes | |
| 42 | | Rename, archive and change the default branch | | | | | Yes | |
| 43 | | Change visibility | | | | | Yes, if the [member privileges](/guides/workspaces/#member-privileges) allow | |
| 44 | | Transfer or delete the repository | | | | | Owners, or Admins if the member privileges allow | |
| 45 | |
| 46 | Everyone can edit and delete their own comments. Maintain and Admin can |
| 47 | edit and delete anyone's; see |
| 48 | [editing and deleting comments](/guides/pull-requests/#editing-and-deleting-comments). |
| 49 | |
| 50 | Changing a repository's visibility, transferring it and deleting it also |
| 51 | depend on its workspace's [member privileges](/guides/workspaces/#member-privileges). |
| 52 | By default, a member with Admin can change visibility, and only an owner |
| 53 | can transfer or delete. Someone given Admin on one repository without being |
| 54 | a member, an outside collaborator, can do none of the three. |
| 55 | |
| 56 | Some things work a little differently on g1t: |
| 57 | |
| 58 | - Whoever opened an issue or pull request can still edit, label and close |
| 59 | their own, whatever their role. |
| 60 | - A [protected branch](/guides/git/#protected-branches) takes no pushes |
| 61 | from anyone, Maintain and Admin included. To let a role push, list it as |
| 62 | a bypass actor of a [ruleset](/guides/rules/) instead. |
| 63 | - Applying a label the repository does not have yet creates it, for |
| 64 | someone with Write. |
| 65 | |
| 66 | Read and Triage cannot put agents to work, or start anything else that |
| 67 | spends compute: runs, plans, workflows and deployments need Write. |
| 68 | |
| 69 | ## How your role is worked out |
| 70 | |
| 71 | Your role on a repository is the highest of: |
| 72 | |
| 73 | 1. **Ownership.** An owner of the workspace has Admin on every repository |
| 74 | in it. |
| 75 | 2. **The base permission.** Every member of the workspace gets the |
| 76 | workspace's [base permission](#the-base-permission) on every repository |
| 77 | in it. |
| 78 | 3. **A role given to you on that repository.** See |
| 79 | [add someone to a repository](#add-someone-to-a-repository). Whoever |
| 80 | creates a repository is given Admin on it this way, so it stays theirs |
| 81 | to run whatever the base permission is. |
| 82 | 4. **Security manager.** A member who is one of the workspace's |
| 83 | [security managers](/guides/workspaces/#roles-that-add-to-a-member) |
| 84 | has Read on every repository, and can see and manage its security |
| 85 | alerts and security settings whatever their role. |
| 86 | 5. **Your teams.** The role each [team](/guides/teams/) you are in has on |
| 87 | that repository, and the roles of that team's parent teams, which child |
| 88 | teams inherit. See [repository access](/guides/teams/#repository-access). |
| 89 | 6. **Public.** Anyone, signed in or not, can read a public repository. |
| 90 | |
| 91 | The highest wins. A member whose base permission is Read and who is given |
| 92 | Maintain on one repository has Maintain there and Read everywhere else. A |
| 93 | role lower than what you already have changes nothing. When a role given to |
| 94 | you and a team's role are the same, the one given to you is shown as where |
| 95 | it comes from. |
| 96 | |
| 97 | A workspace's own [access token](/guides/workspaces/#workspace-access-tokens) |
| 98 | has Write on its workspace's repositories, as a member does, and none on any |
| 99 | other. An owner can give one Admin instead, only when making it. A workflow |
| 100 | job's token and a [deploy key](/guides/git/#deploy-keys) have Write at most, |
| 101 | on their one repository. What is for people only, such as transferring or |
| 102 | deleting a repository, still needs a person. |
| 103 | |
| 104 | A [personal access token](/guides/authentication/#where-a-token-reaches) |
| 105 | made for one workspace has your role only in that workspace's repositories |
| 106 | that it reaches: all of them, the ones chosen, or none. Everywhere else it |
| 107 | reads public repositories, as anyone can, and does nothing more. A token |
| 108 | made for all your workspaces has your role wherever you have one, unless a |
| 109 | workspace's |
| 110 | [rules for tokens](/guides/authentication/#a-workspaces-rules-for-tokens) |
| 111 | keep it out. |
| 112 | |
| 113 | ### Private repositories |
| 114 | |
| 115 | Someone without at least Read on a private repository cannot tell it |
| 116 | exists: its pages answer 404, and the API answers `404` with |
| 117 | `Repository not found.`, the same as for a repository that does not exist. |
| 118 | Someone who can read it but lacks the role for what they tried gets `403` |
| 119 | and a message naming the role they need: |
| 120 | |
| 121 | ```text |
| 122 | You need the Admin role or higher on acme/rocket to do that. |
| 123 | ``` |
| 124 | |
| 125 | ### Git |
| 126 | |
| 127 | | | Needs | |
| 128 | | --- | --- | |
| 129 | | `git clone`, `fetch`, `pull` | Read | |
| 130 | | `git push` | Write | |
| 131 | |
| 132 | A [protected branch](/guides/git/#protected-branches) refuses pushes from |
| 133 | everyone, whatever their role, Admin included; changes reach it through |
| 134 | pull requests. |
| 135 | |
| 136 | ## The base permission |
| 137 | |
| 138 | The base permission is what every member of a workspace gets on every one |
| 139 | of its repositories: |
| 140 | |
| 141 | | Base permission | Members get | |
| 142 | | --- | --- | |
| 143 | | **None** | Nothing beyond what is public. Members see only the private repositories they are given a role on. | |
| 144 | | **Read** | Read on every repository. What a new workspace starts with. | |
| 145 | | **Write** | Write on every repository. | |
| 146 | | **Admin** | Admin on every repository. Transferring and deleting stay with owners unless the member privileges allow them. | |
| 147 | |
| 148 | Owners always have Admin, whatever it says. Only owners can change it: |
| 149 | |
| 150 | 1. Open **People → Members and invites**, `g1t.sh/<workspace>/-/members#base-permission`. Every member can see it; owners manage it. |
| 151 | 2. Under **Base permission**, choose one. |
| 152 | |
| 153 | It takes effect on everyone's next request. To give one member more on |
| 154 | one repository, give them a role there; to give them less, lower the base |
| 155 | permission and give roles to the people who need them. Whoever creates a |
| 156 | repository keeps Admin on it however low the base permission is. |
| 157 | |
| 158 | ### What changed for existing members |
| 159 | |
| 160 | A workspace made from 2026-10-08 starts at **Read**. One made before keeps |
| 161 | the base permission it had, **Write** unless an owner changed it. |
| 162 | |
| 163 | Before roles, every member of a workspace could also change a repository's |
| 164 | settings, its branch protection and guardrails, webhooks, secrets and |
| 165 | variables, deployments and domains. With Write, members keep pushing, |
| 166 | merging and putting agents to work; changing settings now needs Maintain, |
| 167 | and branch protection, rulesets, guardrails and the rest Admin. Owners |
| 168 | have Admin, so they keep all of it. |
| 169 | |
| 170 | On 2026-10-08 the roles were brought in line with the table above: |
| 171 | |
| 172 | - Branch protection, rulesets and guardrails moved from Maintain to Admin. |
| 173 | - Creating, editing and deleting labels and milestones moved from Triage |
| 174 | to Write; Triage still applies them. |
| 175 | - Seeing and dismissing security alerts, secrets included, takes Write; |
| 176 | changing security settings and custom patterns takes Admin. |
| 177 | - Whoever made each existing repository and is still a member of its |
| 178 | workspace was given Admin on it, unless they had it already. |
| 179 | |
| 180 | To give members everything they had before, an owner sets the base |
| 181 | permission to **Admin**. They then also get what only owners could do |
| 182 | before: managing who has access, renaming and archiving repositories, and |
| 183 | changing their visibility and default branch. |
| 184 | |
| 185 | ## Add someone to a repository |
| 186 | |
| 187 | You need Admin on the repository and a confirmed email address. |
| 188 | |
| 189 | 1. Open the repository's **Settings → Access**, |
| 190 | `g1t.sh/<workspace>/<repo>/settings/access`. |
| 191 | 2. Under **Add people**, type a username or an email address. |
| 192 | 3. Pick their role and choose **Add**. |
| 193 | |
| 194 | Everyone with access is listed under **People with access**, with their |
| 195 | role and where it comes from: owner, the base permission, a role given to |
| 196 | them, or **Through team** and the team's slug. **Teams with access** lists the |
| 197 | teams given a role on it, with how many people each has. People with Write |
| 198 | or Maintain can see the lists; changing them needs Admin. |
| 199 | |
| 200 | Giving a role to someone outside the workspace takes an owner when the |
| 201 | workspace's [member privileges](/guides/workspaces/#member-privileges) turn |
| 202 | off **Repository admins can add outside collaborators**. |
| 203 | |
| 204 | Someone with Admin can give a team a role under **Teams with access**: |
| 205 | pick the team and its role, and add it. Only the workspace's own teams can |
| 206 | be added. See [teams](/guides/teams/#repository-access). |
| 207 | |
| 208 | What happens depends on who they are: |
| 209 | |
| 210 | | Who | What happens | |
| 211 | | --- | --- | |
| 212 | | A member of the workspace | They have the role at once. It matters only where it is higher than the base permission. | |
| 213 | | Someone else on g1t | They are sent an [invitation](#invitations) to accept. Typing the confirmed email address of someone on g1t does the same. | |
| 214 | | An email address with no g1t account | g1t emails an invite code that only that address can use. Signing up with it makes their account and accepts the invitation in one step. | |
| 215 | |
| 216 | An invite code to someone without an account uses one of the workspace's |
| 217 | granted invites, or else one of yours (see |
| 218 | [invites](/guides/authentication/#invites)), and works for 30 days. |
| 219 | |
| 220 | On a free workspace, only the first row works: its members can be given a |
| 221 | role, but nobody else can be invited until the workspace starts the g1t |
| 222 | plan. **Add people** says **Start the plan to invite people** above the |
| 223 | form, and an invitation is refused with `402` (`payment_required`). An |
| 224 | invitation sent before cannot be accepted until then. See |
| 225 | [who a free workspace can add](/guides/usage-and-billing/#who-a-free-workspace-can-add). |
| 226 | |
| 227 | To change someone's role, pick another beside their name. To take it away, |
| 228 | choose **Remove**. Removing takes away only the role given on this |
| 229 | repository: an owner's Admin, a member's base permission and what their |
| 230 | teams give them stay. Anyone |
| 231 | can remove their own role from a repository. Each change is confirmed |
| 232 | under the list; one that is refused says why on that person's row. |
| 233 | |
| 234 | ## Outside collaborators |
| 235 | |
| 236 | An outside collaborator has a role on some of a workspace's repositories |
| 237 | without being a member of it. They: |
| 238 | |
| 239 | - see the repositories shared with them under **Shared with you** in the |
| 240 | sidebar, and only those: not the workspace's other private |
| 241 | repositories, its members, settings, usage or billing. The workspace's |
| 242 | page, `g1t.sh/<workspace>`, shows them its public repositories and the |
| 243 | ones shared with them; |
| 244 | - can do on each repository what their role allows, and nothing in the |
| 245 | workspace itself, such as its webhooks, secrets, tokens or integrations; |
| 246 | - are held to whatever the workspace asks of its members, checked when |
| 247 | they are added, when they accept, and on every request after. |
| 248 | |
| 249 | - can put agents to work where they have Write; the runs are charged to |
| 250 | the repository's workspace, and they do not see which model ran or what |
| 251 | it cost. An agent working for them is told the project's memory, never |
| 252 | the workspace's. |
| 253 | |
| 254 | Owners see every outside collaborator, and the repositories and roles each |
| 255 | has, on the **Outside collaborators** tab of the workspace's |
| 256 | **Members and invites** page, `g1t.sh/<workspace>/-/members`. **Invite as a member** sends one an invitation to join the |
| 257 | workspace as a member (see [add people](/guides/workspaces/#add-people)); |
| 258 | once they accept, the roles they have stay, and the base permission adds |
| 259 | to them. |
| 260 | |
| 261 | Removing a member from a workspace, or their leaving it, also removes the |
| 262 | roles they were given on its repositories, and takes them out of its teams. |
| 263 | |
| 264 | A workspace that [requires two-factor authentication](/guides/authentication/#require-two-factor-authentication) |
| 265 | holds its outside collaborators to it as it does its members: without it, |
| 266 | they cannot reach its repositories until they turn it on. |
| 267 | |
| 268 | ## Invitations |
| 269 | |
| 270 | An invitation to someone on g1t waits for them to answer, and they are |
| 271 | emailed a link to it. |
| 272 | |
| 273 | 1. Open `g1t.sh/<workspace>/<repo>/invitations`, the link in the email. |
| 274 | 2. Choose **Accept invitation** or **Decline**. |
| 275 | |
| 276 | Accepting gives you the role; you then find the repository under **Shared |
| 277 | with you**. An invitation lasts **7 days**, then expires. Until it is |
| 278 | answered, it is listed as pending on the repository's **Settings → Access**, |
| 279 | where someone with Admin can change its role or **Revoke** it. To invite |
| 280 | someone again after an expired or declined invitation, add them again. |
| 281 | |
| 282 | ## Agents |
| 283 | |
| 284 | An agent works with the role of the person it acts for, on the |
| 285 | repository it works in, and never more than Write. An owner's agent has |
| 286 | Write, not Admin. So an agent working for you can push, open and merge |
| 287 | pull requests where you can, and cannot change settings, protection, |
| 288 | webhooks or secrets, even when you can. |
| 289 | |
| 290 | An agent's credential can never change who has access: it cannot add, |
| 291 | remove or invite anyone, answer an invitation, or change the base |
| 292 | permission. When the person it works for loses their role on the |
| 293 | repository, or leaves the workspace, the agent loses it too. See |
| 294 | [credentials](/guides/working-with-g1t/#credentials). |
| 295 | |
| 296 | Because putting agents to work spends compute, it needs Write. Someone with |
| 297 | Read or Triage who mentions or assigns an agent is told so, and nothing |
| 298 | starts. |
| 299 | |
| 300 | ## Deploy keys |
| 301 | |
| 302 | A [deploy key](/guides/git/#deploy-keys) is an SSH key that lets a machine |
| 303 | reach one repository: Read, or Write when it was added with write access, |
| 304 | on that repository and no other. It is part of who has access, so managing |
| 305 | deploy keys needs the Admin role: |
| 306 | |
| 307 | | Who | Can list, add and delete a repository's deploy keys | |
| 308 | | --- | --- | |
| 309 | | Someone with the Admin role on it, owners included | Yes | |
| 310 | | Someone with Maintain or less | No | |
| 311 | | An agent, whoever it works for | No | |
| 312 | | A workspace's [access token](/guides/workspaces/#workspace-access-tokens) | Only when an owner gave it Admin | |
| 313 | | A deploy key | No | |
| 314 | |
| 315 | Adding one also needs a confirmed email address. A personal access token |
| 316 | needs the `access:read` scope to list and read them, and `access:admin` to |
| 317 | add and delete them. |
| 318 | |
| 319 | ## Through the API |
| 320 | |
| 321 | Every route is in the [API reference](/reference/api/). Each is also an |
| 322 | action of an [MCP tool](/reference/mcp/): `access` for a repository's |
| 323 | people, its deploy keys and the base permission, `account` for invitations to you. |
| 324 | |
| 325 | | Route | MCP tool and action | What it does | Who | |
| 326 | | --- | --- | --- | --- | |
| 327 | | `GET /repos/{owner}/{name}/collaborators` | `access` `list_collaborators` | Everyone with access to a repository, their role and where it comes from. | Write | |
| 328 | | `GET /repos/{owner}/{name}/collaborators/{username}/permission` | `access` `get_permission` | One person's role on a repository and what it lets them do. | Write, or about yourself | |
| 329 | | `POST /repos/{owner}/{name}/collaborators` | `access` `add_collaborator` | Give someone a role. Body: `invitee` (a username or an email address) and `role`. Answers with `result`: `granted` or `invited`. | Admin | |
| 330 | | `PATCH /repos/{owner}/{name}/collaborators/{username}` | `access` `update_collaborator` | Change someone's role, or a pending invitation's. Body: `role`. | Admin | |
| 331 | | `DELETE /repos/{owner}/{name}/collaborators/{username}` | `access` `remove_collaborator` | Take away the role given to someone on the repository. | Admin, or yourself | |
| 332 | | `GET /repos/{owner}/{name}/invitations` | `access` `list_invitations` | A repository's pending invitations. | Admin | |
| 333 | | `DELETE /repos/{owner}/{name}/invitations/{id}` | `access` `revoke_invitation` | Withdraw a pending invitation. | Admin | |
| 334 | | `GET /user/repository_invitations` | `account` `list_repository_invitations` | The invitations waiting for you. | You | |
| 335 | | `PATCH /user/repository_invitations/{id}` | `account` `accept_repository_invitation` | Accept one. | You | |
| 336 | | `DELETE /user/repository_invitations/{id}` | `account` `decline_repository_invitation` | Decline one. | You | |
| 337 | | `PUT /workspaces/{workspace}/base_permission` | `access` `set_base_permission` | Set the base permission. Body: `base_permission`: `none`, `read`, `write` or `admin`. `PATCH /workspaces/{workspace}` (`workspace` `update`) takes `base_permission` too, with the `access:admin` scope. | Owners | |
| 338 | | `GET /workspaces/{workspace}/outside_collaborators` | `access` `list_outside_collaborators` | A workspace's outside collaborators and the repositories each can reach. | Owners | |
| 339 | | `GET /repos/{owner}/{name}/keys` | `access` `list_deploy_keys` | A repository's [deploy keys](/guides/git/#deploy-keys). | Admin | |
| 340 | | `GET /repos/{owner}/{name}/keys/{id}` | `access` `get_deploy_key` | One deploy key. | Admin | |
| 341 | | `POST /repos/{owner}/{name}/keys` | `access` `add_deploy_key` | Add a deploy key. Body: `title`, `key` and `read_only` (true unless you send false). | Admin | |
| 342 | | `DELETE /repos/{owner}/{name}/keys/{id}` | `access` `remove_deploy_key` | Delete a deploy key. | Admin | |
| 343 | |
| 344 | Changing who has access, answering an invitation and setting the base |
| 345 | permission are for people, signed in or with a personal access token. |
| 346 | |
| 347 | Roles are written `read`, `triage`, `write`, `maintain` and `admin`. |
| 348 | |
| 349 | ```sh |
| 350 | curl https://api.g1t.sh/repos/acme/rocket/collaborators/ada/permission \ |
| 351 | -H "Authorization: Bearer $G1T_TOKEN" |
| 352 | ``` |
| 353 | |
| 354 | ```json |
| 355 | { |
| 356 | "username": "ada", |
| 357 | "role": "write", |
| 358 | "source": "base", |
| 359 | "capabilities": ["read", "participate", "triage", "push", "merge", "manage_labels", "security_alerts", "run"] |
| 360 | } |
| 361 | ``` |
| 362 | |
| 363 | `source` is `owner`, `base`, `direct` or `team`. In the list from |
| 364 | `list_collaborators`, each person also has `direct`, the role given to them |
| 365 | on the repository if any, and `team_role` and `team`: the highest role a |
| 366 | team gives them there, and that team's slug. A team's own roles are managed |
| 367 | through the [teams API](/guides/teams/#through-the-api). |
| 368 | |
| 369 | ## Webhooks and the audit log |
| 370 | |
| 371 | A change to someone's role on a repository is sent to |
| 372 | [webhooks](/guides/webhooks/) as one of: |
| 373 | |
| 374 | | Event | When | |
| 375 | | --- | --- | |
| 376 | | `repo.collaborator_added` | Someone was given a role on the repository, or accepted an invitation. | |
| 377 | | `repo.collaborator_role_changed` | Their role changed. `data.role` and `data.previous_role`. | |
| 378 | | `repo.collaborator_removed` | Their role was taken away. | |
| 379 | |
| 380 | Each has `data.username`, `data.role` and `data.previous_role`. |
| 381 | |
| 382 | The workspace's [audit log](/guides/audit-log/) records the same changes |
| 383 | under those names, and also `repo.invitation_created`, |
| 384 | `repo.invitation_revoked`, `workspace.base_permission_changed`, and |
| 385 | `repo.deploy_key_added` and `repo.deploy_key_removed` for |
| 386 | [deploy keys](#deploy-keys). A repository's creator being given Admin is |
| 387 | not recorded: it comes with `repo.created`. |
| 388 | |
| 389 | A team's role on a repository changing is sent as `team.repo_added`, |
| 390 | `team.repo_role_changed` or `team.repo_removed`; see |
| 391 | [teams](/guides/teams/#webhooks-and-the-audit-log). |