| 1 | --- |
| 2 | title: Accounts and authentication |
| 3 | description: Accounts, invites, email addresses, confirming them, two-factor authentication and recovery codes, fine-grained and classic personal access tokens, scopes and permissions, a workspace's rules for tokens, OAuth, signing in from a tool, password reset, your security log and deleting your account. |
| 4 | --- |
| 5 | |
| 6 | ## Creating an account |
| 7 | |
| 8 | g1t is invite-only for now: to make an account you need an |
| 9 | [invite](#invites). Open the link in your invite, or enter its code at |
| 10 | [g1t.sh/register](https://g1t.sh/register). Without one, ask for access |
| 11 | on the same page. Usernames are lowercase letters, digits and single |
| 12 | hyphens, up to 39 characters. |
| 13 | |
| 14 | Before you can do anything else, you [confirm your email |
| 15 | address](#confirming-your-email-address) with the code g1t emails you, |
| 16 | unless you signed up from the link in an invite g1t emailed to that address |
| 17 | (see [invites from your inbox](#invites-from-your-inbox)). |
| 18 | |
| 19 | Accounts can only be created in a browser. There is no API for it, by |
| 20 | design: it keeps passwords out of scripts and agents, and lets g1t protect |
| 21 | the one place accounts are made. |
| 22 | |
| 23 | ## Your settings |
| 24 | |
| 25 | Your own settings are at [g1t.sh/settings](https://g1t.sh/settings), one |
| 26 | page each. Open them from your account menu at the bottom of the sidebar, |
| 27 | under **Your settings**; the sidebar then lists every page. |
| 28 | |
| 29 | | Page | Address | What is on it | |
| 30 | | --- | --- | --- | |
| 31 | | Profile | [`/settings/profile`](https://g1t.sh/settings/profile) | Your picture, and your [public profile](/guides/workspaces/#profiles): name, pronouns, bio, location, website and time zone. | |
| 32 | | Emails | [`/settings/emails`](https://g1t.sh/settings/emails) | Your [email addresses](#email-addresses), the backup address, and [keeping your address private](#keeping-your-address-private). | |
| 33 | | Invites to g1t | [`/settings/invites`](https://g1t.sh/settings/invites) | [Making, copying and revoking invites to g1t](#making-invites), while g1t is invite-only; after that, the invites you made. | |
| 34 | | SSH keys | [`/settings/keys`](https://g1t.sh/settings/keys) | Public keys for [git over SSH](/guides/git/#ssh), each with when it was added and last used. | |
| 35 | | Access tokens | [`/settings/tokens`](https://g1t.sh/settings/tokens) | Your [personal access tokens](#access-tokens): fine-grained and classic. | |
| 36 | | GitHub | [`/settings/github`](https://g1t.sh/settings/github) | [Linking and unlinking GitHub](/guides/github/#link-and-unlink-github). | |
| 37 | | Connected applications | [`/settings/applications`](https://g1t.sh/settings/applications) | Tools you [signed in to with OAuth](#signing-in-with-oauth), such as an agent using the MCP server. | |
| 38 | | Two-factor authentication | [`/settings/two-factor`](https://g1t.sh/settings/two-factor) | [An authenticator app and recovery codes](#two-factor-authentication). | |
| 39 | | Security log | [`/settings/security-log`](https://g1t.sh/settings/security-log) | [What happened to your account](#security-log). | |
| 40 | | Account | [`/settings/account`](https://g1t.sh/settings/account) | Your username, and [deleting your account](#deleting-your-account). | |
| 41 | |
| 42 | `g1t.sh/settings` opens Profile. |
| 43 | |
| 44 | ## Signing in with GitHub |
| 45 | |
| 46 | **Continue with GitHub** on the sign-in and sign-up pages signs you in with |
| 47 | your GitHub account, and makes a g1t account the first time. Link or |
| 48 | unlink GitHub in [Settings → GitHub](https://g1t.sh/settings/github). See |
| 49 | [GitHub](/guides/github/#sign-in-with-github). |
| 50 | |
| 51 | Making an account with GitHub needs an invite too: start from your invite |
| 52 | link, or enter the code when g1t asks for it after GitHub. |
| 53 | |
| 54 | With [two-factor authentication](#two-factor-authentication) on, signing in |
| 55 | with GitHub asks for a code from your app as well. |
| 56 | |
| 57 | ## Two-factor authentication |
| 58 | |
| 59 | Two-factor authentication asks for a code from an authenticator app on |
| 60 | your phone each time you sign in with your password or with GitHub, so a |
| 61 | stolen password is not enough. Any app that reads a time-based one-time |
| 62 | password (TOTP) QR code works, such as 1Password, Google Authenticator or |
| 63 | Authy. |
| 64 | |
| 65 | ### Turn it on |
| 66 | |
| 67 | 1. Open [Settings → Two-factor authentication](https://g1t.sh/settings/two-factor) |
| 68 | and choose **Set up**. g1t asks for your password if you have not |
| 69 | signed in in the last 10 minutes. |
| 70 | 2. Scan the QR code with your app, or type the key shown under it. |
| 71 | 3. Enter the six-digit code the app shows, and choose **Turn on**. |
| 72 | 4. Save the ten recovery codes g1t shows. They are shown only then. |
| 73 | |
| 74 | ### Signing in with it on |
| 75 | |
| 76 | After your password (or GitHub), g1t asks for the code from your app. A |
| 77 | code works for 30 seconds, and the one before and after it are accepted |
| 78 | too, for a phone clock a little off. Each code works once. After five wrong |
| 79 | codes, or ten minutes, start the sign-in again. |
| 80 | |
| 81 | Lost your phone? Enter a recovery code instead of the app's code. Each |
| 82 | works once, and your security log records its use. |
| 83 | |
| 84 | Git over HTTPS never takes your password while two-factor authentication |
| 85 | is on: use a [personal access token](#access-tokens) as the password, or |
| 86 | [SSH](/guides/git/). Access tokens, SSH keys and OAuth applications are |
| 87 | not affected. |
| 88 | |
| 89 | ### Recovery codes, and turning it off |
| 90 | |
| 91 | On the same page: |
| 92 | |
| 93 | - **Make new recovery codes** replaces all ten; the old ones stop working. |
| 94 | - **Turn off** needs a code from your app or a recovery code, and your |
| 95 | password if you have not signed in in the last 10 minutes. |
| 96 | |
| 97 | You cannot turn it off while you own a workspace that |
| 98 | [requires it](/guides/workspaces/#require-two-factor-authentication): stop |
| 99 | requiring it there first, or hand the workspace to another owner. In a |
| 100 | workspace that requires it, turning it off holds you out of that workspace |
| 101 | until you turn it on again. |
| 102 | |
| 103 | Turning it on or off, and making new recovery codes, are emailed to your |
| 104 | primary and backup addresses, written to your [security log](#security-log), |
| 105 | and recorded in the [audit log](/guides/audit-log/) of each of your |
| 106 | workspaces as `two_factor.enabled` and `two_factor.disabled`. |
| 107 | |
| 108 | ### Require two-factor authentication |
| 109 | |
| 110 | An owner can require it of everyone with access to a workspace. See |
| 111 | [Workspaces](/guides/workspaces/#require-two-factor-authentication). |
| 112 | |
| 113 | Passkeys are not supported yet; they are next. |
| 114 | |
| 115 | ## Invites |
| 116 | |
| 117 | There are two kinds of invite, and they do different things: |
| 118 | |
| 119 | | | Invite to g1t | Invite to a workspace | |
| 120 | | --- | --- | --- | |
| 121 | | Made from | [Settings → Invites](https://g1t.sh/settings/invites), your own | The workspace's **People** page, by its owners | |
| 122 | | What it gives | One new account. It adds them to no workspace: the account gets a workspace of its own | An invitation to join that workspace, which they accept or decline | |
| 123 | | Someone without an account | Makes their account with it | Makes their account with it too, while g1t is invite-only, then answers the invitation | |
| 124 | | Someone already on g1t | Nothing: they have an account | The invitation, in their inbox and by email | |
| 125 | | Exists | Only while g1t is invite-only | Always | |
| 126 | | What its page and email say | "@syntaqx invited you to g1t" | "@syntaqx invited you to join Flagon, Inc. on g1t" | |
| 127 | |
| 128 | So you can invite someone to g1t without inviting them into any |
| 129 | workspace; an invite to g1t only adds them to a workspace when you tick |
| 130 | **Also invite them to a workspace** (see [making invites](#making-invites)). |
| 131 | |
| 132 | While g1t is invite-only, every new account needs an invite code, such as |
| 133 | `g1t-k7m2-q9xd-…`. People already on g1t make them, and g1t sends them to |
| 134 | people who [asked for access](#asking-for-access). An invite: |
| 135 | |
| 136 | - works once, for one new account; |
| 137 | - works for 30 days; |
| 138 | - when it was made for an email address, works only with that address; |
| 139 | - can be revoked by whoever made it until it is used, and after that until |
| 140 | the new account [confirms its email address](#confirming-your-email-address). |
| 141 | |
| 142 | ### Using an invite |
| 143 | |
| 144 | Every invite email links to `g1t.sh/invite/<code>`. That one page shows |
| 145 | who sent it and what it is for (joining a workspace, collaborating on a |
| 146 | repository, or just making an account), and finishes the job there: |
| 147 | |
| 148 | 1. **No account yet**: sign up on the page. When the invite was sent to |
| 149 | your address, the email field is filled in and locked. Choose a |
| 150 | username (one is suggested from your address) and a password. If you |
| 151 | opened the page from the invite email itself, the address is already |
| 152 | confirmed and you go straight in (see |
| 153 | [invites from your inbox](#invites-from-your-inbox)); otherwise |
| 154 | [confirm the address](#confirming-your-email-address) with the code g1t |
| 155 | emails it. Or select **Continue with GitHub**: the invite rides along, |
| 156 | and the account uses the invited address when GitHub has verified it |
| 157 | too, in which case no confirmation is needed. |
| 158 | 2. **The address already has an account**: select **Sign in to accept**. |
| 159 | After you sign in, the invite is accepted for you. |
| 160 | 3. **Signed in as someone else**: an invite sent to one address works only |
| 161 | for an account that has confirmed that address. The page says so and |
| 162 | offers **Sign out and continue**. |
| 163 | |
| 164 | Nobody joins a workspace without saying yes. With an existing account, |
| 165 | accepting on the invite's page is that yes: you land in the workspace (or |
| 166 | the repository) the invite was for, with a one-time "You're in" banner, |
| 167 | and it becomes the workspace your sidebar shows. |
| 168 | |
| 169 | A new account made from an invite that names a workspace is invited to |
| 170 | it: once the account's address is confirmed, g1t takes you to |
| 171 | [g1t.sh/invitations](https://g1t.sh/invitations), where you |
| 172 | [accept or decline](#workspace-invitations) it. Until you answer, you have |
| 173 | no workspace of your own, so you never end up with two. An invite that |
| 174 | names no workspace gives the new account a workspace of its own instead; |
| 175 | see [your first workspace](#your-first-workspace). |
| 176 | |
| 177 | Signing up spends the invite at once, so nobody else can use it while you |
| 178 | confirm your address. Until you confirm, the invite shows as **confirming |
| 179 | their email** to whoever made it, and they can still revoke it. If the |
| 180 | invite is revoked or expires, or its workspace is deleted, before you |
| 181 | confirm, your address is confirmed all the same and g1t tells you the |
| 182 | invite no longer applies: ask whoever invited you to invite you again. A |
| 183 | code typed at [g1t.sh/register](https://g1t.sh/register) goes to the |
| 184 | same page. |
| 185 | |
| 186 | An expired, revoked or used invite says which, and who sent it, so you |
| 187 | can ask them for a new one; or ask for access from the same page. |
| 188 | |
| 189 | ### Invites from your inbox |
| 190 | |
| 191 | When g1t emails an invite to an address (an invite you make for someone, |
| 192 | an owner's invite into a workspace or a repository, or an approved |
| 193 | [request for access](#asking-for-access)), the link in that email carries a |
| 194 | `proof` that only the email has: `g1t.sh/invite/<code>?proof=…`. Opening |
| 195 | the link shows that you can read that inbox, so: |
| 196 | |
| 197 | - the invite page says the address is confirmed because you came from the |
| 198 | invite email, and the email field stays locked to it; |
| 199 | - your new account starts with the address confirmed: no code is sent. A |
| 200 | repository the invite was for is yours straight away; a workspace it |
| 201 | names is a [workspace invitation](#workspace-invitations) you accept or |
| 202 | decline straight away, since nobody joins a workspace without saying yes. |
| 203 | |
| 204 | Anything else confirms the address the usual way, after you sign up: the |
| 205 | code typed at [g1t.sh/register](https://g1t.sh/register), an invite link |
| 206 | copied from **Settings → Invites** (whoever made the invite sees the code, |
| 207 | never the proof), an invite made for anyone with the link, or an invite |
| 208 | email sent before this existed. The proof is tied to one invite and its |
| 209 | address, and stops working when the invite is used, revoked or expires. |
| 210 | |
| 211 | ### Invite links for a group |
| 212 | |
| 213 | g1t sometimes hands one link to a group: an event's judges, readers of a |
| 214 | post, a community. It looks like |
| 215 | `https://g1t.sh/register?invite=g1t-k7m2-…` and opens sign-up with the |
| 216 | code filled in and the group named above the form, such as **Invited as |
| 217 | part of Launch week judges**. |
| 218 | |
| 219 | - **It makes your own account.** Each person who uses it gets a new |
| 220 | account, and then makes their own workspace. It does not add you to |
| 221 | anyone else's workspace; once you are in, a workspace's owners can add |
| 222 | you from its People page. |
| 223 | - **It may be for some email domains only.** When it is, the email field |
| 224 | says which, such as `example.com`, and sign-up takes only an address |
| 225 | there. Use your address at that organization; you confirm it like any |
| 226 | other. |
| 227 | - **It works a set number of times, until a set day.** Once every place |
| 228 | is taken, or the day has passed, or g1t has stopped it, the link gets |
| 229 | the same answer as any invite that cannot be used. Ask whoever shared |
| 230 | it, or [ask for access](#asking-for-access). |
| 231 | |
| 232 | Using the link spends one place in the same step that makes your account, |
| 233 | so two people signing up at the same moment can never take more places |
| 234 | than it has. Anyone with an account can still [make invites](#making-invites) |
| 235 | of their own; group links are made by g1t staff only. |
| 236 | |
| 237 | ### Making invites |
| 238 | |
| 239 | These are invites to g1t. They let one person make an account, and add |
| 240 | them to no workspace unless you say so. |
| 241 | |
| 242 | 1. Open [Settings → Invites](https://g1t.sh/settings/invites) (**Invites |
| 243 | to g1t** in your settings and account menu). |
| 244 | 2. Optionally enter the email address of the person you are inviting. |
| 245 | With one, g1t emails them the invite, and only that address can use it. |
| 246 | Without one, anyone with the link can, once. |
| 247 | 3. Optionally tick **Also invite them to a workspace**, then choose the |
| 248 | workspace and the role (**Member** or **Owner**) they are invited with. |
| 249 | It is off to start with, and no workspace is chosen for you, not even |
| 250 | the one you are in. |
| 251 | 4. Select **Create invite**, then copy the link. |
| 252 | |
| 253 | Left unticked, the invite is to g1t only: the new account gets a |
| 254 | [workspace of its own](#your-first-workspace). Ticked, the new account |
| 255 | gets a [workspace invitation](#workspace-invitations) to the workspace you |
| 256 | chose once its address is confirmed, and is not given a workspace of its |
| 257 | own. The list of workspaces holds the ones you can add members to: the ones |
| 258 | you own that are on the g1t plan. A workspace on the free plan cannot add |
| 259 | people, so it is not offered, and the form says so when it is the one you |
| 260 | are in. |
| 261 | |
| 262 | To bring someone into a workspace, you do not need an invite to g1t: |
| 263 | invite them from the workspace's People page instead (see |
| 264 | [inviting someone into a workspace](#inviting-someone-into-a-workspace)). |
| 265 | Settings → Invites links to the People pages of the workspaces you own. |
| 266 | |
| 267 | Once anyone can sign up for g1t, there are no invites to g1t to make: |
| 268 | Settings → Invites keeps only the list of invites you already made, and |
| 269 | says that anyone can sign up now and that workspace invitations live on |
| 270 | each workspace's People page. With no invites made, the page is not listed |
| 271 | in your settings or account menu. |
| 272 | |
| 273 | Each person can have **5** invites out at a time. Pending and used invites |
| 274 | count; an invite you revoke, or one that expires before anyone uses it, |
| 275 | comes back to you. The list under the form shows each invite's state: |
| 276 | pending, confirming their email (used to sign up by someone who has not |
| 277 | confirmed their address yet), waiting for them to accept (the account is |
| 278 | made and confirmed, and the workspace invitation waits for its answer), |
| 279 | joined (with the username of who joined), declined, expired or revoked. You |
| 280 | must confirm your email before you can make invites. An agent's token and |
| 281 | a workspace's token cannot make them. |
| 282 | |
| 283 | ### Inviting someone into a workspace |
| 284 | |
| 285 | An owner can invite someone into a workspace from its People page, by |
| 286 | username or by email address, with the role they join as; see |
| 287 | [add people](/guides/workspaces/#add-people). Nobody is added without |
| 288 | saying yes: someone on g1t gets a [workspace invitation](#workspace-invitations) |
| 289 | to accept or decline. When an address has no g1t account, the invitation |
| 290 | also lets it make one first, and the invitation is answered once the |
| 291 | account's address is confirmed (at once when it was made from the invite |
| 292 | email's link). While g1t is invite-only, that uses one invite: one of the |
| 293 | workspace's shared invites when it has any, otherwise one of yours. Once |
| 294 | anyone can sign up, it costs nothing. Inviting someone who is already on |
| 295 | g1t never costs anything. |
| 296 | |
| 297 | ### Workspace invitations |
| 298 | |
| 299 | A workspace invitation asks one account to join one workspace, with the |
| 300 | role chosen when it was sent. You hear of it in your inbox and by email, |
| 301 | and answer it at [g1t.sh/invitations](https://g1t.sh/invitations): |
| 302 | |
| 303 | - **Accept** joins the workspace with that role, and takes you there. |
| 304 | - **Decline** joins nothing; whoever invited you is told in their inbox. |
| 305 | |
| 306 | An invitation works for 30 days, the same as an invite. Until it is |
| 307 | answered, the workspace's owners see it under **Pending invitations** on |
| 308 | its People page and can revoke it. A workspace on the free plan cannot add |
| 309 | people, so an invitation to one cannot be accepted until it starts the |
| 310 | plan. Only you can answer your invitations: an agent's token and a |
| 311 | workspace's token cannot. |
| 312 | |
| 313 | ### Your first workspace |
| 314 | |
| 315 | Everything on g1t lives in a workspace, so every new account gets one: |
| 316 | |
| 317 | - An account whose invite brings it into a workspace gets the invitation |
| 318 | to it, and no workspace of its own. |
| 319 | - Every other account (signed up with a password, with GitHub, from a |
| 320 | shared invite link or an invite from g1t staff, or with an invite that |
| 321 | names no workspace) gets a workspace of its own, named for its username, |
| 322 | on the free plan. Rename it or start the plan on it whenever you like. |
| 323 | |
| 324 | Signed in without any workspace (you declined an invitation, or left the |
| 325 | only workspace you were in), g1t shows **Create your workspace or ask to |
| 326 | join one** in place of Mission control: the invitations waiting for you, if |
| 327 | any, and the form to create a workspace. To join a team already on g1t, |
| 328 | ask one of its owners to invite you by your username. |
| 329 | |
| 330 | ### Need more invites? |
| 331 | |
| 332 | Write to [hey@flagon.io](mailto:hey@flagon.io?subject=%5Bg1t%20Invites%5D%20) |
| 333 | with the subject `[g1t Invites]` and say who you would like to bring. g1t |
| 334 | can give more invites to you, or to a workspace, whose owners then share |
| 335 | them. Invites given to a workspace appear under |
| 336 | [Settings → Invites](https://g1t.sh/settings/invites) for |
| 337 | each of its owners, as a choice of whose invites to use. |
| 338 | |
| 339 | ### Asking for access |
| 340 | |
| 341 | Without an invite, [g1t.sh/register](https://g1t.sh/register) asks for your |
| 342 | email address and, if you like, what you will build. g1t emails that |
| 343 | address once to confirm you are on the list, and staff see the request |
| 344 | straight away. When they approve it, the invite comes to the same address, |
| 345 | sometimes with a note, and its link opens sign-up with the address filled |
| 346 | in. There is no fixed date: g1t opens up a few people at a time. Asking |
| 347 | again with the same address updates your request without another email; it |
| 348 | does not move you down the list. |
| 349 | |
| 350 | ### Invites through the API |
| 351 | |
| 352 | | Route | MCP tool and action | What it does | |
| 353 | | --- | --- | --- | |
| 354 | | [`GET /user/invites`](/reference/api/invites/list-invites/) | `account` `list_invites` | Your invites and how many you have left | |
| 355 | | [`POST /user/invites`](/reference/api/invites/create-invite/) | `account` `create_invite` | Make an invite, optionally for one `email`; with `workspace` (a slug), the new account is invited to that workspace | |
| 356 | | [`DELETE /user/invites/{id}`](/reference/api/invites/revoke-invite/) | `account` `revoke_invite` | Revoke a pending invite, or one whose new account has not confirmed its address | |
| 357 | | [`POST /workspaces/{workspace}/invitations`](/reference/api/invites/invite-member/) | `workspace` `invite_member` | Invite a `username` or an `email` into a workspace, with a `role`. Owners only. | |
| 358 | | [`GET /user/invitations`](/reference/api/invites/list-invitations/) | `account` `list_workspace_invitations` | The workspace invitations waiting for your answer | |
| 359 | | [`POST /user/invitations/{id}/accept`](/reference/api/invites/accept-invitation/) | `account` `accept_workspace_invitation` | Join the invitation's workspace with its role | |
| 360 | | [`POST /user/invitations/{id}/decline`](/reference/api/invites/decline-invitation/) | `account` `decline_invitation` | Decline it; whoever sent it is told | |
| 361 | |
| 362 | ## Confirming your email address |
| 363 | |
| 364 | A new account confirms its email address before it can do anything else on |
| 365 | g1t, unless it already has (it was made with GitHub, or from the link in |
| 366 | its invite email). Right after you sign up, g1t emails the address from `noreply@g1t.sh` |
| 367 | with two ways to confirm it, either one enough: |
| 368 | |
| 369 | - a **six-digit code**, shown large in the email (and in its subject, so a |
| 370 | phone's notification shows it). Type it on the **Confirm your email** |
| 371 | page g1t takes you to. On a phone, the keyboard offers it from the |
| 372 | message. |
| 373 | - a **link**, for when you would rather click than type. It works whether |
| 374 | or not you are signed in, in any browser. |
| 375 | |
| 376 | The code and the link work for **60 minutes**, once. Using either ends the |
| 377 | other. **Send a new code** on the confirmation page sends a fresh code and |
| 378 | link, at most once a minute and 10 times an hour, and the ones before stop |
| 379 | working. |
| 380 | |
| 381 | | On the confirmation page | What it does | |
| 382 | | --- | --- | |
| 383 | | **Confirm email** | Checks the code. A wrong, used or expired code gets the same answer. After 10 wrong codes in an hour, codes for the account are not checked for a while (a minute, then longer); the link in the email still works. Wrong codes from one network are limited the same way. | |
| 384 | | **Send a new code** | A new code and link; the ones before stop working. | |
| 385 | | **Wrong address? Change it** | Replaces the address you signed up with and sends the new one a code. Only while the account has no confirmed address. | |
| 386 | | **Sign out** | Signs out. Sign in again to come back to the page. | |
| 387 | |
| 388 | ### Until you confirm |
| 389 | |
| 390 | An account that has not confirmed its address can only confirm it: |
| 391 | |
| 392 | - **The site** sends every page to the confirmation page, and back to where |
| 393 | you were going once you confirm. Signing in and out, password resets, |
| 394 | the confirmation link, and g1t's [policies](https://g1t.sh/policies), |
| 395 | security, support, status and pricing pages stay open. |
| 396 | - **The API** answers `403` with a message saying to confirm your address, |
| 397 | except for [`GET /user`](/reference/api/accounts/whoami/), |
| 398 | [`GET /user/emails`](/reference/api/accounts/list-emails/) and |
| 399 | [`POST /user/emails/confirm`](/reference/api/accounts/confirm-email/). |
| 400 | - **The MCP server** answers `403` with the same message. |
| 401 | - **Git** over HTTPS refuses pushes and fetches with your credentials, with |
| 402 | the same message. Package registries treat them as wrong credentials. |
| 403 | - You cannot create a workspace, answer the invitation your invite brought, make |
| 404 | invites or tokens, or approve a tool's sign-in. |
| 405 | |
| 406 | You cannot make a token before you confirm, so the API and MCP refusals |
| 407 | matter only for an account that made one before this rule existed. |
| 408 | |
| 409 | ### Addresses GitHub has confirmed |
| 410 | |
| 411 | An account made with **Continue with GitHub** starts confirmed: its address |
| 412 | is one GitHub has verified, so GitHub has already proved the inbox is |
| 413 | yours, and no code is sent. |
| 414 | |
| 415 | ### Addresses an invite email has confirmed |
| 416 | |
| 417 | An account made from the link in the invite g1t emailed to its address |
| 418 | starts confirmed the same way: following that link proved the inbox is |
| 419 | yours. It works only for the address the invite was sent to, and only from |
| 420 | the email's own link; see [invites from your inbox](#invites-from-your-inbox). |
| 421 | |
| 422 | ### Accounts that never confirmed |
| 423 | |
| 424 | Accounts are confirmed once and stay confirmed. An account made before this |
| 425 | rule that never confirmed its address, or whose address another account |
| 426 | confirmed first, is held at the confirmation page the same way the next |
| 427 | time it signs in; **Send a new code** gets it a code, and **Change it** |
| 428 | gives it a new address. |
| 429 | |
| 430 | ### Confirming through the API |
| 431 | |
| 432 | | Route | MCP tool and action | What it does | |
| 433 | | --- | --- | --- | |
| 434 | | [`POST /user/emails/confirm`](/reference/api/accounts/confirm-email/) | `account` `confirm_email` | Confirm an address with the `code` from its email | |
| 435 | |
| 436 | The answer says whether the account is now confirmed (`verified`), the |
| 437 | workspace its invite invites it to (`invited_to`: accept or decline it with |
| 438 | [`POST /user/invitations/{id}/accept`](/reference/api/invites/accept-invitation/) |
| 439 | or [`/decline`](/reference/api/invites/decline-invitation/)), or why its |
| 440 | invite no longer applies (`invite_lapsed`). `joined` is always null: nothing |
| 441 | is joined without an answer. |
| 442 | |
| 443 | ## Email addresses |
| 444 | |
| 445 | An account can have up to 10 email addresses. Manage them in |
| 446 | [Settings → Emails](https://g1t.sh/settings/emails). |
| 447 | |
| 448 | | An address that is | Can | |
| 449 | | --- | --- | |
| 450 | | Primary | Get account mail and password reset links. Exactly one, always confirmed once any address is. | |
| 451 | | Confirmed | Sign you in (type it instead of your username), ask for a password reset, and mark commits that carry it as yours. | |
| 452 | | Backup | Get security notices as well as the primary. Optional, and a confirmed address other than the primary. | |
| 453 | | Unconfirmed | Nothing yet. It is not yours until you enter the code or follow the link g1t sent it. | |
| 454 | |
| 455 | A confirmed address belongs to one account. Anyone can add an address they |
| 456 | have not confirmed; the first account to confirm it keeps it, and the |
| 457 | address leaves every other account that added it. An address another |
| 458 | account has confirmed cannot be added. |
| 459 | |
| 460 | ### Add an address |
| 461 | |
| 462 | 1. Open [Settings → Emails](https://g1t.sh/settings/emails). |
| 463 | 2. Enter the address under **Add an email address** and select **Add**. |
| 464 | 3. Enter the code g1t emails it, or follow the link in the same email. |
| 465 | Both work for 60 minutes; **Resend link** sends a new code and link, at |
| 466 | most once a minute and 10 times an hour, and ends the ones before. |
| 467 | |
| 468 | If your account had no confirmed address yet, the first one you confirm |
| 469 | becomes your primary. |
| 470 | |
| 471 | ### Choose your primary and backup |
| 472 | |
| 473 | Select **Make primary** beside a confirmed address. Under **Backup |
| 474 | address**, choose a confirmed address to get security notices too, or |
| 475 | **Primary address only**. |
| 476 | |
| 477 | ### Remove an address |
| 478 | |
| 479 | Select **Remove** beside it. You cannot remove your primary address (make |
| 480 | another one primary first) or your last confirmed address. |
| 481 | |
| 482 | ### Confirming it is you |
| 483 | |
| 484 | Adding or removing an address, changing your primary or backup, and |
| 485 | turning two-factor authentication on or off, need proof that it is you: a |
| 486 | sign-in in the last 10 minutes, or your password, |
| 487 | which g1t asks for on the page. After you enter it, g1t does not ask again |
| 488 | for 10 minutes. An account that signs in only with GitHub signs out and in |
| 489 | with GitHub again, or sets a password with |
| 490 | [Forgot your password](https://g1t.sh/forgot). |
| 491 | |
| 492 | Each of these changes is emailed to every confirmed address on the account, |
| 493 | including an address that was just removed, and written to your |
| 494 | [security log](#security-log). |
| 495 | |
| 496 | ### Keeping your address private |
| 497 | |
| 498 | **Keep my email address private** is on for every account unless you turn |
| 499 | it off. While it is on, commits g1t makes for you (merging a pull request |
| 500 | on the web, catching a branch up, and commits an agent makes for you) carry |
| 501 | your noreply address instead of your primary: |
| 502 | |
| 503 | ``` |
| 504 | <8 characters of your account id>+<username>@users.noreply.g1t.sh |
| 505 | ``` |
| 506 | |
| 507 | The page shows yours. It never receives mail. Turn the setting off to put |
| 508 | your primary address on those commits instead. |
| 509 | |
| 510 | **Block pushes that expose my email** refuses a push that would publish one |
| 511 | of your addresses while you keep it private. When both settings are on, |
| 512 | g1t reads the new commits in each push you make, and declines the push if |
| 513 | any of them has one of your confirmed addresses as its author or committer |
| 514 | address. git shows why, with the address masked: |
| 515 | |
| 516 | ``` |
| 517 | remote: push declined: commit 3f9a1c2 would publish s***@gmail.com while your email is private. |
| 518 | remote: Commit with 6c1d0efg+sam@users.noreply.g1t.sh (git config user.email 6c1d0efg+sam@users.noreply.g1t.sh) and amend, |
| 519 | remote: or change this in g1t.sh/settings/emails. |
| 520 | ``` |
| 521 | |
| 522 | To push those commits: |
| 523 | |
| 524 | 1. Set your noreply address for the repository: |
| 525 | `git config user.email <your noreply address>`. |
| 526 | 2. Rewrite the commits with it. For the last commit, |
| 527 | `git commit --amend --reset-author --no-edit`; for several, |
| 528 | `git rebase <base> --exec "git commit --amend --reset-author --no-edit"`. |
| 529 | 3. Push again. |
| 530 | |
| 531 | Only your own addresses are checked: commits by other people in the same |
| 532 | push go through, and so does your noreply address. A push an agent makes |
| 533 | for you follows your settings. |
| 534 | |
| 535 | ### How commits are attributed |
| 536 | |
| 537 | g1t shows a commit as yours, with your picture and a link to your profile, |
| 538 | when its author address is one of your confirmed addresses or your noreply |
| 539 | address. Commits that g1t made for you before noreply addresses existed |
| 540 | (`<username>@users.g1t.sh`) count as yours too. An unconfirmed address |
| 541 | never attributes a commit, so nobody can claim your commits by adding your |
| 542 | address. Commits whose address matches no account show the name in the |
| 543 | commit. See [Commits and your account](/guides/workspaces/#commits-and-your-account) |
| 544 | for setting your noreply address in git. |
| 545 | |
| 546 | ### Email addresses through the API |
| 547 | |
| 548 | | Route | MCP tool and action | What it does | |
| 549 | | --- | --- | --- | |
| 550 | | [`GET /user/emails`](/reference/api/accounts/list-emails/) | `account` `list_emails` | Your addresses and email settings | |
| 551 | | [`POST /user/emails`](/reference/api/accounts/add-email/) | `account` `add_email` | Add an address; takes `email` and `password` | |
| 552 | | [`POST /user/emails/confirm`](/reference/api/accounts/confirm-email/) | `account` `confirm_email` | Confirm an address with the `code` from its email | |
| 553 | | [`DELETE /user/emails/{email}`](/reference/api/accounts/remove-email/) | `account` `remove_email` | Remove an address; takes `password` | |
| 554 | | [`PATCH /user/email-settings`](/reference/api/accounts/update-email-settings/) | `account` `update_email_settings` | Change `primary`, `backup`, `private_email` or `block_private_pushes` | |
| 555 | |
| 556 | Through the API, `password` is the proof a sensitive change needs. Without |
| 557 | it, or with the wrong one, the answer is `403` with the code |
| 558 | `reauth_required`. Only a person's own token can use these: an agent's |
| 559 | token and a workspace's token are refused. |
| 560 | |
| 561 | ## Workspaces |
| 562 | |
| 563 | Your account does not own repositories itself: a workspace does. A new |
| 564 | account gets one of its own, named for its username, unless its invite |
| 565 | brings it into one; see [your first workspace](#your-first-workspace). Workspaces, |
| 566 | their members and roles, and the access tokens that belong to a workspace |
| 567 | are covered in [workspaces](/guides/workspaces/). |
| 568 | |
| 569 | ## Access tokens |
| 570 | |
| 571 | A token stands in for your password everywhere outside the website: |
| 572 | |
| 573 | | Where | How to send it | |
| 574 | | --- | --- | |
| 575 | | git | As the password, with your username. | |
| 576 | | API | `Authorization: Bearer g1t_…` | |
| 577 | | MCP | The same header, set when you add the server. | |
| 578 | |
| 579 | A token is shown once, when it is created; g1t stores only a hash of it. |
| 580 | If you lose one, delete it and create another. Delete a token the moment |
| 581 | you think someone else has seen it. |
| 582 | |
| 583 | There are two kinds of personal access token, on two tabs of |
| 584 | [Settings → Access tokens](https://g1t.sh/settings/tokens): |
| 585 | |
| 586 | | | Fine-grained token | Classic token | |
| 587 | | --- | --- | --- | |
| 588 | | Reaches | One resource owner: one workspace you belong to, or your own account | Every workspace and repository you can reach, including ones you join later | |
| 589 | | Repositories | All of the workspace's, the ones you choose (up to 50), or public ones only | All you can reach | |
| 590 | | What it may do | A level for each [permission](#permissions) | Its [scopes](#scopes) | |
| 591 | | Expires | Always, within 366 days | 7 days to 1 year, or never | |
| 592 | | A workspace can | Require an owner's approval first, or keep them out | Keep them out | |
| 593 | |
| 594 | Both never do more than you could on the website, and both are sent the |
| 595 | same way. Prefer a fine-grained token: it reaches only what it needs. |
| 596 | |
| 597 | For CI and integrations that work for a team, a workspace can have tokens |
| 598 | of its own that act as the workspace and keep working when their creator |
| 599 | leaves. See [workspace tokens](#workspace-tokens). |
| 600 | |
| 601 | ### Create a fine-grained token |
| 602 | |
| 603 | 1. Open [Settings → Access tokens](https://g1t.sh/settings/tokens). The |
| 604 | **Fine-grained tokens** tab is first. |
| 605 | 2. Under **New fine-grained token**, give it a **Token name** after what |
| 606 | will use it, and optionally a **Description**, which a workspace's |
| 607 | owners see if they review it. |
| 608 | 3. Choose the **Resource owner**: a workspace you belong to, or **Your |
| 609 | account**. A workspace that does not allow fine-grained tokens cannot be |
| 610 | chosen. |
| 611 | 4. Choose its **Expiration**: 7, 30, 60, 90 or 180 days, or 1 year, or |
| 612 | less when the workspace sets a shorter limit. |
| 613 | 5. Under **Repository access**, choose **Public repositories** (read-only), |
| 614 | **All repositories** of the workspace (including ones made later), or |
| 615 | **Only select repositories**, and tick up to 50. |
| 616 | 6. Under **Permissions**, set each one the token needs to **Read-only** or |
| 617 | **Read and write** (and **Admin** for packages). **Metadata** is always |
| 618 | read-only. Each row shows the g1t scopes its level gives. |
| 619 | 7. Select **Generate token**, and copy it. It is not shown again. |
| 620 | |
| 621 | When the workspace [requires approval](#a-workspaces-rules-for-tokens) and |
| 622 | you are not one of its owners, the token is made **Pending approval**: it |
| 623 | works at once, but reads public repositories only until an owner approves |
| 624 | it. The owners hear of it in their [inbox](/guides/inbox/), and you hear of |
| 625 | their answer in yours. An owner's own token never waits. |
| 626 | |
| 627 | Select **Edit** on a token to change its name, description, repositories |
| 628 | or permissions. The token stays the same. Widening it in a workspace that |
| 629 | requires approval asks again. Its resource owner and expiry cannot change; |
| 630 | make a new token instead. |
| 631 | |
| 632 | The list shows each token's status (pending, denied or revoked, with the |
| 633 | owner's note), what it reaches, its permissions, and when it was made, last |
| 634 | used and expires. |
| 635 | |
| 636 | ### Permissions |
| 637 | |
| 638 | Each level of a fine-grained token's permissions gives g1t |
| 639 | [scopes](#scopes), and the token is checked by those scopes |
| 640 | exactly as a classic token is. Where two permissions give the same scopes |
| 641 | (Checks and Commit statuses; Secrets and Variables; Deployments and Pages), |
| 642 | giving either gives both. |
| 643 | |
| 644 | Repository permissions, for a workspace as the resource owner: |
| 645 | |
| 646 | | Permission | Levels | What it covers | g1t scopes it gives | |
| 647 | | --- | --- | --- | --- | |
| 648 | | `actions` (Actions) | read, write | Workflow runs, jobs, logs and artifacts: reading them, and running, cancelling and rerunning workflows | read: `workflows:read`; write: `workflows:write` | |
| 649 | | `administration` (Administration) | read, write | Repository settings, rulesets, who has access and deploy keys; renaming, archiving, transferring and deleting | read: `repo:read`, `access:read`; write: `repo:admin`, `access:admin` | |
| 650 | | `agents` (g1t agents) | write | Putting g1t's agents to work and messaging them, which uses the workspace's money | write: `agents:run` | |
| 651 | | `checks` (Checks) | read, write | Check runs and check suites on commits. Shares its scopes with Commit statuses | read: `checks:read`; write: `checks:write` | |
| 652 | | `contents` (Contents) | read, write | Code, branches, commits and releases: cloning and fetching, pushing, and publishing releases | read: `code:read`; write: `code:write`, `repo:write` | |
| 653 | | `deployments` (Deployments) | read, write | Deployments and their statuses | read: `deployments:read`; write: `deployments:write` | |
| 654 | | `environments` (Environments) | read, write | Environments, and their secrets and variables | read: `deployments:read`, `secrets:read`; write: `secrets:admin` | |
| 655 | | `issues` (Issues) | read, write | Issues, their comments, labels and milestones, and plans | read: `issues:read`; write: `issues:write` | |
| 656 | | `memory` (Memory and context) | read, write | Recalling memory and searching the workspace's context, and saving memory for the next agent | read: `memory:read`; write: `memory:write` | |
| 657 | | `metadata` (Metadata) | read | Seeing repositories and searching them. Always read | read: `repo:read` | |
| 658 | | `packages` (Packages) | read, write, admin | Pulling private packages, publishing them, and (admin) deleting packages and versions | read: `packages:read`; write: `packages:write`; admin: `packages:delete` | |
| 659 | | `pages` (Pages) | read, write | Deployments on g1t.page. Shares its scopes with Deployments | read: `deployments:read`; write: `deployments:write` | |
| 660 | | `pull_requests` (Pull requests) | read, write | Pull requests, their reviews, changes, sessions and merge queues | read: `pull_requests:read`; write: `pull_requests:write` | |
| 661 | | `secrets` (Secrets) | read, write | Actions secrets: listing them (never their values), setting and deleting them. Shares its scopes with Variables | read: `secrets:read`; write: `secrets:admin` | |
| 662 | | `security_events` (Security events and alerts) | read, write | Code scanning, secret scanning and vulnerability alerts, SARIF uploads and security settings | read: `security:read`; write: `security:write` | |
| 663 | | `statuses` (Commit statuses) | read, write | Statuses on commits. Shares its scopes with Checks | read: `checks:read`; write: `checks:write` | |
| 664 | | `variables` (Variables) | read, write | Actions variables: reading, setting and deleting them. Shares its scopes with Secrets | read: `secrets:read`; write: `secrets:admin` | |
| 665 | | `webhooks` (Webhooks) | read, write | Webhooks and their deliveries | read: `webhooks:read`; write: `webhooks:admin` | |
| 666 | | `workflows` (Workflows) | write | Adding, changing and deleting workflow files under .g1t/workflows and .github/workflows. Write only | write: `workflow_files:write` | |
| 667 | |
| 668 | Workspace permissions, for a workspace as the resource owner: |
| 669 | |
| 670 | | Permission | Levels | What it covers | g1t scopes it gives | |
| 671 | | --- | --- | --- | --- | |
| 672 | | `members` (Members) | read, write | The workspace's people, invitations and teams | read: `workspace:read`; write: `workspace:admin` | |
| 673 | | `workspace_administration` (Administration) | read, write | The workspace's settings, integrations, rulesets and base permission | read: `workspace:read`, `access:read`; write: `workspace:admin`, `access:admin` | |
| 674 | | `workspace_billing` (Billing) | read, write | Usage, budget, AI credit and invoices, and (write) changing the budget and buying credit | read: `billing:read`; write: `billing:write` | |
| 675 | | `models` (AI Gateway) | read, write | AI Gateway requests: seeing them, and sending requests, which uses the workspace's AI credit | read: `models:read`; write: `models:write` | |
| 676 | | `self_hosted_runners` (Self-hosted runners) | read, write | Runners, their groups and settings | read: `runners:read`; write: `runners:admin` | |
| 677 | | `workspace_secrets` (Secrets) | read, write | The workspace's Actions secrets. Shares its scopes with the repository Secrets permission | read: `secrets:read`; write: `secrets:admin` | |
| 678 | | `workspace_webhooks` (Webhooks) | read, write | The workspace's webhooks. Shares its scopes with the repository Webhooks permission | read: `webhooks:read`; write: `webhooks:admin` | |
| 679 | |
| 680 | Account permissions, for your own account as the resource owner: |
| 681 | |
| 682 | | Permission | Levels | What it covers | g1t scopes it gives | |
| 683 | | --- | --- | --- | --- | |
| 684 | | `email_addresses` (Email addresses) | read, write | Your email addresses and email settings, invites and invitations | read: `account:read`; write: `account:write` | |
| 685 | | `starring` (Starring) | read, write | Stars and pinned projects. Shares its scopes with Email addresses | read: `account:read`; write: `account:write` | |
| 686 | | `notifications` (Notifications) | read, write | Your inbox, subscriptions and watched repositories | read: `notifications:read`; write: `notifications:write` | |
| 687 | |
| 688 | ### What a fine-grained token reaches |
| 689 | |
| 690 | - **In its workspace**, what your role allows, in the repositories it |
| 691 | reaches, and only what its permissions give. |
| 692 | - **Elsewhere**, public repositories, read-only, as anyone can. It cannot |
| 693 | comment, open issues or push there. |
| 694 | - **With your account as its resource owner**, public repositories, |
| 695 | read-only, and what its account permissions give. |
| 696 | - **While pending, denied or revoked**, public repositories, read-only. |
| 697 | |
| 698 | A request it cannot make answers `403` naming why: the scope it lacks, or |
| 699 | `This fine-grained token's resource owner is the workspace acme: it can only |
| 700 | read public repositories elsewhere, …`. A repository outside its selection |
| 701 | answers as if it did not exist. |
| 702 | |
| 703 | ### Create a classic token |
| 704 | |
| 705 | 1. Open [Settings → Access tokens](https://g1t.sh/settings/tokens), and |
| 706 | select the **Tokens (classic)** tab. |
| 707 | 2. Under **New classic token**, give it a **Name** after what will use it. |
| 708 | 3. Choose when it **Expires**: 7 days, 30 days, 90 days (the default), |
| 709 | 1 year, or No expiry. An expired token stops working; make a new one. |
| 710 | No expiry shows a warning: the token works until someone deletes it. |
| 711 | 4. Under **Scopes**, tick the boxes for what it may do. They are grouped |
| 712 | by area. The form starts on the **Agent** [preset](#presets); select |
| 713 | another preset to tick its boxes instead. |
| 714 | 5. Select **Create token**, and copy the token. It is not shown again. |
| 715 | |
| 716 | The list shows each token's name, when it was made and last used, when it |
| 717 | expires, and its access: a preset's name, its scopes, or Full access. To |
| 718 | change what a token may do, select **Edit access**, tick or untick boxes, |
| 719 | and select **Save access**. The token stays the same; the change applies |
| 720 | from its next request. |
| 721 | |
| 722 | A classic token reaches every workspace you belong to unless the |
| 723 | workspace's [rules](#a-workspaces-rules-for-tokens) keep it out: one that |
| 724 | does not allow classic tokens, one whose longest lifetime this token |
| 725 | exceeds, or one whose owner revoked it there. It keeps working everywhere |
| 726 | else. |
| 727 | |
| 728 | ## Scopes |
| 729 | |
| 730 | A scope is a resource and a level, written `resource:level`, such as |
| 731 | `issues:write`. A higher level includes the lower ones of the same |
| 732 | resource: `repo:admin` includes `repo:write`, which includes `repo:read`. |
| 733 | It never includes another resource: `repo:admin` does not let a token push, |
| 734 | which is `code:write`. |
| 735 | |
| 736 | On the form, scopes are a checklist grouped by area: |
| 737 | |
| 738 | | Group | Scopes | |
| 739 | | --- | --- | |
| 740 | | Repositories & code | `repo:read`, `repo:write`, `code:read`, `code:write` | |
| 741 | | Packages | `packages:read`, `packages:write` | |
| 742 | | Issues & pull requests | `issues:read`, `issues:write`, `pull_requests:read`, `pull_requests:write` | |
| 743 | | Agents | `agents:run` | |
| 744 | | Workflows | `workflows:read`, `workflows:write`, `workflow_files:write` | |
| 745 | | Checks | `checks:read`, `checks:write` | |
| 746 | | Deployments | `deployments:read`, `deployments:write` | |
| 747 | | Memory & search | `memory:read`, `memory:write` | |
| 748 | | Account | `account:read`, `account:write` | |
| 749 | | Notifications | `notifications:read`, `notifications:write` | |
| 750 | | Security | `security:read`, `security:write` | |
| 751 | | Workspace | `workspace:read`, `access:read`, `webhooks:read`, `secrets:read` | |
| 752 | | Billing | `billing:read`, `billing:write` | |
| 753 | | Runners | `runners:read` | |
| 754 | | AI Gateway | `models:read`, `models:write` | |
| 755 | | Dangerous | `repo:admin`, `packages:delete`, `workspace:admin`, `access:admin`, `webhooks:admin`, `secrets:admin`, `runners:admin` | |
| 756 | |
| 757 | Ticking a higher level ticks the lower ones of its resource and greys |
| 758 | them out: tick `issues:write` and `issues:read` is ticked too. Untick |
| 759 | `issues:write` and `issues:read` stays ticked. |
| 760 | |
| 761 | | Scope | What it lets a token do | |
| 762 | | --- | --- | |
| 763 | | `repo:read` | See repositories, their settings, labels, timelines, releases, languages, contributors and security alerts, and search | |
| 764 | | `repo:write` | Create repositories, rename branches, change how pull requests merge and publish releases | |
| 765 | | `repo:admin` | Rename, archive, transfer, delete or change who can see a repository, and dismiss security alerts | |
| 766 | | `code:read` | Clone and fetch private repositories with git | |
| 767 | | `code:write` | Push commits with git | |
| 768 | | `security:read` | See [secret scanning](/guides/security/secret-protection/), [code scanning](/guides/security/code-scanning/) and vulnerability alerts, custom patterns, the dependency graph and SBOM, and security settings | |
| 769 | | `security:write` | Dismiss and reopen alerts, bypass push protection, review bypass requests, manage custom patterns, upload SARIF and change security settings | |
| 770 | | `packages:read` | Pull container images and install private [packages](/guides/packages/). Public ones need no scope. | |
| 771 | | `packages:write` | Push container images and publish packages; with the Admin role on a package, change its settings | |
| 772 | | `packages:delete` | Delete and restore packages and their versions | |
| 773 | | `issues:read` | Read issues, comments and plans | |
| 774 | | `issues:write` | Open, edit, close and comment on issues | |
| 775 | | `pull_requests:read` | Read pull requests, their changes, sessions and merge queues | |
| 776 | | `pull_requests:write` | Open, review, close and merge pull requests | |
| 777 | | `agents:run` | Put g1t to work and message it, which uses the workspace's money | |
| 778 | | `workflows:read` | Read workflows, runs and logs | |
| 779 | | `workflows:write` | Run, cancel, rerun and turn workflows on or off | |
| 780 | | `workflow_files:write` | Add, change and delete [workflow files](#workflow-files) under `.g1t/workflows` and `.github/workflows`, with git or the API. Not in any preset but full access. | |
| 781 | | `checks:read` | Read commits' statuses, check runs, check suites and annotations | |
| 782 | | `checks:write` | Report [statuses and check runs](/guides/checks/) on commits, and ask for checks to run again | |
| 783 | | `deployments:read` | See [deployments](/guides/deployments-api/), their statuses and environments | |
| 784 | | `deployments:write` | Report deployments and their statuses, from any CI | |
| 785 | | `memory:read` | Recall memory and search the workspace's context | |
| 786 | | `memory:write` | Save memory for the next agent | |
| 787 | | `account:read` | Read your email addresses, invites, invitations, pinned projects and stars | |
| 788 | | `account:write` | Change your email addresses, make invites, answer invitations, pin projects and star repositories | |
| 789 | | `notifications:read` | See your [inbox](/guides/inbox/), its threads, and what you subscribe to and watch | |
| 790 | | `notifications:write` | Mark notifications read, done, saved or snoozed, subscribe to threads and watch repositories | |
| 791 | | `workspace:read` | Read workspace settings, invites, integrations, model routes and [teams](/guides/teams/) | |
| 792 | | `workspace:admin` | Create and delete workspaces, invite members, manage teams, connect integrations | |
| 793 | | `billing:read` | See a workspace's [usage, budget, AI credit and invoices](/guides/usage-and-billing/) | |
| 794 | | `billing:write` | Change a workspace's budget and buy AI credit. Only owners, as people: a workspace's own token and g1t's agents never change billing, whatever their scopes. Not in any preset but full access. | |
| 795 | | `access:read` | See who has access to repositories | |
| 796 | | `access:admin` | Give people and teams access to repositories, and take it away | |
| 797 | | `webhooks:read` | See webhooks and their deliveries | |
| 798 | | `webhooks:admin` | Create, change and delete webhooks | |
| 799 | | `secrets:read` | List secrets (never their values) and read variables | |
| 800 | | `secrets:admin` | Set and delete secrets and variables | |
| 801 | | `runners:read` | See [self-hosted runners](/guides/self-hosted-runners/), their groups and where agents run. Not in the Agent preset. | |
| 802 | | `runners:admin` | Register and remove self-hosted runners, change their groups and settings | |
| 803 | | `models:read` | See the workspace's [AI Gateway](/guides/ai-gateway/) requests: their models, tokens, cost and status | |
| 804 | | `models:write` | Send model requests through the [AI Gateway](/guides/ai-gateway/), which uses the workspace's AI credit. Only a workspace's own token can send them. Not in any preset but full access. | |
| 805 | |
| 806 | Every operation of the API and the MCP server needs exactly one of these, |
| 807 | except `whoami` (`GET /user`), which any token may use. Each endpoint's page |
| 808 | in the [API reference](/reference/api/) names its scope, and so does each |
| 809 | action in [MCP tools](/reference/mcp/). A few calls need a second scope for |
| 810 | what they ask: |
| 811 | |
| 812 | | Call | Also needs | |
| 813 | | --- | --- | |
| 814 | | `delegate` (`POST /repos/{owner}/{name}/issues/delegate`, the `agent` tool's `delegate`), which opens an issue | `issues:write`, beside `agents:run` | |
| 815 | | `apply_plan` or `import_issue` (the `plan` tool's `apply`, the `issue` tool's `import`) with `assign: true` | `agents:run` | |
| 816 | | `update_repo` with `private` or `default_branch` | `repo:admin` | |
| 817 | |
| 818 | ### What a token can do |
| 819 | |
| 820 | What a request may do is where these overlap: |
| 821 | |
| 822 | 1. **Your role.** A token never does more than you could on the website. A |
| 823 | token with `repo:admin` still cannot delete a repository unless you are |
| 824 | an owner of its workspace. See [access and roles](/guides/access-and-roles/). |
| 825 | 2. **What it reaches.** A classic token, every workspace and repository you |
| 826 | can reach, including ones you join later, unless a workspace's |
| 827 | [rules](#a-workspaces-rules-for-tokens) keep it out. A fine-grained |
| 828 | token, its [resource owner](#what-a-fine-grained-token-reaches) only. |
| 829 | 3. **Its scopes.** What kinds of thing it may do: chosen directly on a |
| 830 | classic token, given by its permissions on a fine-grained one. |
| 831 | |
| 832 | To keep a token away from other workspaces, make a fine-grained one, or use |
| 833 | a [workspace token](#workspace-tokens): it reaches only its own workspace. |
| 834 | |
| 835 | ### Presets |
| 836 | |
| 837 | A preset ticks a starting set of boxes. Select one, then tick or untick |
| 838 | any box. |
| 839 | |
| 840 | | Preset | Scopes | |
| 841 | | --- | --- | |
| 842 | | Read only | Every `read` scope. Changes nothing. | |
| 843 | | Agent | Every `read` scope except `runners:read`, and `code:write`, `issues:write`, `pull_requests:write`, `agents:run`, `memory:write` and `notifications:write`. Reads everything, works on issues and pull requests, pushes code, puts g1t to work, and answers your inbox. No admin scope. | |
| 844 | | CI | `repo:read`, `code:read`, `code:write`, `packages:read`, `packages:write`, `workflows:read`, `workflows:write`, `checks:read`, `checks:write`, `deployments:read` and `deployments:write`. Clones and pushes code, pushes and pulls packages, runs workflows, and reports [checks](/guides/checks/) and deployments. | |
| 845 | | Full access | Everything you can do, including deleting repositories and changing who has access. Marked **Dangerous**. | |
| 846 | |
| 847 | Admin scopes change things that are hard to undo, or decide who can reach |
| 848 | what. They are under **Dangerous**, with a warning. Give them only to |
| 849 | something you trust as much as yourself. |
| 850 | |
| 851 | ### Git and scopes |
| 852 | |
| 853 | Over HTTPS, git checks the same token: |
| 854 | |
| 855 | | To | Needs | |
| 856 | | --- | --- | |
| 857 | | Clone or fetch a public repository | No scope | |
| 858 | | Clone or fetch a private repository | `code:read` | |
| 859 | | Push | `code:write` | |
| 860 | | Push commits that add, change or delete [workflow files](#workflow-files) | `code:write` and `workflow_files:write` | |
| 861 | |
| 862 | Your role on the repository applies too, as on the website. A refused push |
| 863 | or clone says which scope is missing. |
| 864 | |
| 865 | ### Workflow files |
| 866 | |
| 867 | A workflow runs with its repository's secrets and a token of its own, so |
| 868 | changing one is as powerful as holding those. A token therefore needs |
| 869 | `workflow_files:write` (a fine-grained token's **Workflows** permission) to |
| 870 | add, change or delete any file under `.g1t/workflows/` or |
| 871 | `.github/workflows/`, besides `code:write`: |
| 872 | |
| 873 | - **With git**, every commit a push adds is compared with its parent, and a |
| 874 | push that changes a workflow file is declined, naming it: |
| 875 | |
| 876 | ```text |
| 877 | remote: This access token cannot change the workflow file .github/workflows/ci.yml: it needs the workflow_files:write scope. |
| 878 | remote: Push with a token that has the workflow_files:write scope, or make the change signed in on g1t.sh. |
| 879 | ``` |
| 880 | |
| 881 | A push too large for g1t to read whole is declined for such a token too, |
| 882 | since it cannot be checked; push it in smaller parts. |
| 883 | - **Through g1t**, a file written for a token (such as a starter workflow) |
| 884 | is refused the same way. |
| 885 | - **A workflow job's token** never may, whatever its `permissions:` say. |
| 886 | See [the job's token](/guides/actions/#the-jobs-token). |
| 887 | - **Signed in on g1t.sh**, your role decides, as for any file. |
| 888 | |
| 889 | Full-access tokens, and tokens made before scopes, include it. A |
| 890 | [deploy key](/guides/git/#deploy-keys) with write access may change |
| 891 | workflow files. |
| 892 | |
| 893 | ### When a token lacks a scope |
| 894 | |
| 895 | The API answers `403` with the scope that was missing in `needed_scope`: |
| 896 | |
| 897 | ```json |
| 898 | { |
| 899 | "error": { |
| 900 | "code": "forbidden", |
| 901 | "message": "This access token needs the issues:write scope to use create_issue.", |
| 902 | "needed_scope": "issues:write" |
| 903 | } |
| 904 | } |
| 905 | ``` |
| 906 | |
| 907 | Through MCP the same message comes back as a tool result with `isError` |
| 908 | set. Give the token that scope with **Edit access**, or make a new token. |
| 909 | |
| 910 | ### Tokens made before scopes |
| 911 | |
| 912 | Tokens and OAuth sign-ins made before tokens had scopes keep full access, |
| 913 | so nothing that uses them stops working. Settings marks each one |
| 914 | **Legacy · full access**, and says to narrow it to what it needs. For a |
| 915 | token, select **Narrow this token**; for an application, **Change access** |
| 916 | in [Connected applications](https://g1t.sh/settings/applications). Then |
| 917 | tick its scopes. A token you make with Full access on purpose is not marked |
| 918 | legacy. |
| 919 | |
| 920 | A token from [signing in from a tool](#signing-in-from-a-tool), such as the |
| 921 | g1t CLI, has full access. |
| 922 | |
| 923 | ### Workspace tokens |
| 924 | |
| 925 | A workspace's own tokens act as the workspace rather than a person. An |
| 926 | owner makes them in the workspace's **Settings → Access tokens**, with the |
| 927 | same checklist and expiry choices; the form starts on the CI preset. A |
| 928 | workspace token reaches all of that workspace's repositories, never |
| 929 | another workspace, and cannot manage people, tokens or workspaces. |
| 930 | |
| 931 | It has the Write role on the workspace's repositories, as a member does: |
| 932 | it pushes, merges and works on issues and pull requests, within its scopes. |
| 933 | Tick **Admin on the workspace's repositories** when making it to give it |
| 934 | Admin instead, so it can also manage webhooks, secrets, deploy keys and who |
| 935 | has access, and manage teams as an owner would. Only an owner can, and only |
| 936 | when making it. See |
| 937 | [workspace access tokens](/guides/workspaces/#workspace-access-tokens). |
| 938 | |
| 939 | ## A workspace's rules for tokens |
| 940 | |
| 941 | An owner decides which of the members' own personal tokens reach the |
| 942 | workspace, under its **Settings → Personal access tokens** |
| 943 | (`g1t.sh/<workspace>/-/personal-access-tokens`). The rules apply from each |
| 944 | token's next request, to tokens made before them too. A token they keep out |
| 945 | keeps working everywhere else, and reads the workspace's public |
| 946 | repositories as anyone can. |
| 947 | |
| 948 | | Rule | Default | What it does | |
| 949 | | --- | --- | --- | |
| 950 | | Allow fine-grained personal access tokens | On | Off: no fine-grained token can name the workspace as its resource owner, and existing ones stop reaching it. | |
| 951 | | Require approval of fine-grained tokens | On | A member's fine-grained token naming the workspace waits for an owner's approval, and again when it is widened. Owners' own tokens never wait. | |
| 952 | | Allow classic personal access tokens | On | Off: classic tokens no longer reach the workspace. | |
| 953 | | Tokens must expire | Off | On: a token that never expires does not reach the workspace. | |
| 954 | | Longest lifetime | No limit | A token that lasts longer (from when it was made to when it expires), or never expires, does not reach the workspace. Fine-grained tokens for it cannot be made longer. | |
| 955 | |
| 956 | The same page lists: |
| 957 | |
| 958 | - **Waiting for approval.** Each pending fine-grained token with its owner, |
| 959 | permissions, repositories and expiry. Add an optional note, then select |
| 960 | **Approve** or **Deny**. Its owner hears of it in their inbox, with the |
| 961 | note. |
| 962 | - **Tokens that can reach the workspace.** Every fine-grained token naming |
| 963 | it, and every classic token of its members and outside collaborators that |
| 964 | has not expired, with its owner, permissions or scopes, last use and |
| 965 | expiry, and whether it reaches the workspace now (and if not, why). Never |
| 966 | the token itself. Select **Revoke** to take one out: a fine-grained token |
| 967 | stops reaching the workspace for good; a classic token keeps working |
| 968 | everywhere else, but never reaches this workspace again. |
| 969 | |
| 970 | Approvals, denials, revocations and rule changes are |
| 971 | [audit log](/guides/audit-log/) entries: `token.approval_requested`, |
| 972 | `token.approved`, `token.denied`, `token.revoked` and |
| 973 | `token.policy_changed`. |
| 974 | |
| 975 | ### A workspace's rules through the API |
| 976 | |
| 977 | Owners, as people (a personal token with the scope works; a workspace's own |
| 978 | token does not): |
| 979 | |
| 980 | | Route | MCP tool and action | What it does | Scope | |
| 981 | | --- | --- | --- | --- | |
| 982 | | [`GET /workspaces/{workspace}/personal-access-token-policy`](/reference/api/personal-access-tokens/get-token-policy/) | `workspace` `get_token_policy` | The rules. Members may read them. | `workspace:read` | |
| 983 | | [`PATCH /workspaces/{workspace}/personal-access-token-policy`](/reference/api/personal-access-tokens/set-token-policy/) | `workspace` `set_token_policy` | Change `allow_classic`, `allow_fine_grained`, `require_approval`, `max_lifetime_days` (0 for no limit) or `forbid_no_expiry` | `workspace:admin` | |
| 984 | | [`GET /workspaces/{workspace}/personal-access-tokens`](/reference/api/personal-access-tokens/list-member-tokens/) | `workspace` `list_member_tokens` | The tokens that can reach it; `kind` is `classic` or `fine_grained` | `access:read` | |
| 985 | | [`GET /workspaces/{workspace}/personal-access-token-requests`](/reference/api/personal-access-tokens/list-token-requests/) | `workspace` `list_token_requests` | The fine-grained tokens waiting for approval | `access:read` | |
| 986 | | [`POST /workspaces/{workspace}/personal-access-token-requests/{id}`](/reference/api/personal-access-tokens/review-token-request/) | `workspace` `review_token_request` | `decision` is `approve` or `deny`, with an optional `reason` | `access:admin` | |
| 987 | | [`POST /workspaces/{workspace}/personal-access-tokens/{id}`](/reference/api/personal-access-tokens/revoke-member-token/) | `workspace` `revoke_member_token` | Revoke a token in the workspace, with an optional `reason` | `access:admin` | |
| 988 | |
| 989 | ## Signing in with OAuth |
| 990 | |
| 991 | Applications that can open your browser, such as an agent connecting to the |
| 992 | [MCP server](/guides/bring-your-own-agent/), sign you in with OAuth 2.1. |
| 993 | You see a page on g1t naming the application and where it will send you |
| 994 | back, and you approve or deny. The application never sees your password and |
| 995 | there is no token to copy. |
| 996 | |
| 997 | The page lists what the application will be able to do, as the same |
| 998 | checklist a token has, with only the scopes it asked for, all ticked. |
| 999 | Untick anything you would rather it could not do, leaving at least one; |
| 1000 | you cannot give it more than it asked for. Like a token, it reaches |
| 1001 | everything you can. |
| 1002 | |
| 1003 | An application that asks for no scopes in particular gets the |
| 1004 | [Agent preset](#presets): every `read` scope except `runners:read`, and `code:write`, |
| 1005 | `issues:write`, `pull_requests:write`, `agents:run`, `memory:write` and |
| 1006 | `notifications:write`. |
| 1007 | It never gets an admin scope unless it asks for one and you leave it |
| 1008 | ticked. |
| 1009 | |
| 1010 | Applications you have approved are listed in |
| 1011 | [Settings → Connected applications](https://g1t.sh/settings/applications), |
| 1012 | each with its access. Select **Change access** to tick or untick its |
| 1013 | scopes, then **Save access**: it stays signed in, the change applies at |
| 1014 | once, and its next refresh keeps it. Select **Sign out** to end its access |
| 1015 | at once. |
| 1016 | |
| 1017 | For people building a client: |
| 1018 | |
| 1019 | | | | |
| 1020 | | --- | --- | |
| 1021 | | Metadata | `https://api.g1t.sh/.well-known/oauth-authorization-server` | |
| 1022 | | Authorization | `https://g1t.sh/oauth/authorize` | |
| 1023 | | Token | `https://api.g1t.sh/oauth/token` | |
| 1024 | | Registration | `https://api.g1t.sh/oauth/register` | |
| 1025 | |
| 1026 | - The flow is authorization code with PKCE. `S256` is required. |
| 1027 | - Clients are public: there are no client secrets. |
| 1028 | - Register with `client_name` and `redirect_uris`. A redirect address is an |
| 1029 | `https` URL, `http` on `localhost`, or the application's own scheme. A |
| 1030 | client on `localhost` may use any port. |
| 1031 | - Registration stores nothing. The client id it returns encodes what was |
| 1032 | registered, so it cannot be used to fill g1t with junk. |
| 1033 | - Ask for scopes with `scope` on the authorization request, separated by |
| 1034 | spaces, such as `scope=repo:read issues:write pull_requests:write`. |
| 1035 | Names g1t does not know are left out. Leave `scope` out for the Agent |
| 1036 | preset. The authorization server's metadata and |
| 1037 | `https://mcp.g1t.sh/.well-known/oauth-protected-resource` list every |
| 1038 | scope in `scopes_supported`. |
| 1039 | - The token response's `scope` holds the scopes the person granted, |
| 1040 | separated by spaces, or `*` for a sign-in with full access. Refreshing |
| 1041 | keeps them. |
| 1042 | - An access token lasts 30 days. The refresh token returned with it works |
| 1043 | once and returns the next pair; the previous access token stops working. |
| 1044 | - An authorization code lasts five minutes and works once. |
| 1045 | |
| 1046 | ## Signing in from a tool |
| 1047 | |
| 1048 | A tool that cannot receive a redirect, such as a script on a remote machine, |
| 1049 | gets a token without ever handling your password: |
| 1050 | |
| 1051 | 1. The tool asks g1t for a code and shows you a link and a short code such |
| 1052 | as `WDJB-MJHT`. |
| 1053 | 2. You open the link, sign in (or create an account), check that the code |
| 1054 | matches, and approve. |
| 1055 | 3. The tool collects its token. |
| 1056 | |
| 1057 | ```sh |
| 1058 | # 1. The tool starts a sign-in. |
| 1059 | curl -X POST https://api.g1t.sh/device/code -H "Content-Type: application/json" -d '{"client_name": "my-tool"}' |
| 1060 | |
| 1061 | # 2. You open verification_uri_complete from the response and approve. |
| 1062 | |
| 1063 | # 3. The tool polls, no faster than "interval" seconds, until it is approved. |
| 1064 | curl -X POST https://api.g1t.sh/device/token -H "Content-Type: application/json" -d '{"device_code": "…"}' |
| 1065 | ``` |
| 1066 | |
| 1067 | The poll answers with a `status` of `pending`, `approved`, `denied` or |
| 1068 | `expired`. An approved answer carries the token, once. Codes expire after 15 |
| 1069 | minutes. The token appears in |
| 1070 | [Settings → Access tokens](https://g1t.sh/settings/tokens) under the tool's name, where you |
| 1071 | can delete it. |
| 1072 | |
| 1073 | Only approve a code you asked for. The token has full access: it can do |
| 1074 | everything you can. To give a tool less, make an |
| 1075 | [access token](#create-a-fine-grained-token) with only the scopes it needs instead. |
| 1076 | |
| 1077 | ## Resetting your password |
| 1078 | |
| 1079 | Use [g1t.sh/forgot](https://g1t.sh/forgot) and enter any confirmed |
| 1080 | address of your account. The link goes to that address and works for one |
| 1081 | hour; your primary and backup addresses are told a reset was asked for |
| 1082 | when it went elsewhere. A new account that has not confirmed its address |
| 1083 | yet can use that address, and following the link confirms it. |
| 1084 | |
| 1085 | The page answers the same way whether or not the address has an account. |
| 1086 | g1t sends at most 5 reset links an hour to one address. If g1t cannot |
| 1087 | take the request at all, the page says so and keeps what you typed, so you |
| 1088 | can try again. |
| 1089 | |
| 1090 | Setting a new password signs you out everywhere and emails your primary |
| 1091 | and backup addresses. |
| 1092 | |
| 1093 | ## Too many attempts |
| 1094 | |
| 1095 | g1t counts wrong passwords, on the sign-in page, for git over HTTPS and |
| 1096 | when confirming it is you, against the account and against where they come |
| 1097 | from. After 10 wrong passwords for one account in an hour, or 30 from one |
| 1098 | place, g1t stops checking passwords for it for a minute, then twice as long |
| 1099 | after each further wrong password, up to an hour. While it waits, every |
| 1100 | attempt gets the same answer: "Too many attempts". The account's primary |
| 1101 | and backup addresses are told the first time. Signing in with the right |
| 1102 | password, or resetting it, clears the count. Access tokens, SSH keys and |
| 1103 | GitHub sign-in are not affected. |
| 1104 | |
| 1105 | ## Security log |
| 1106 | |
| 1107 | [Settings → Security log](https://g1t.sh/settings/security-log) lists what |
| 1108 | happened to your account: addresses added, confirmed, removed or made |
| 1109 | primary, your backup and privacy settings, password changes, pauses after |
| 1110 | too many wrong passwords, two-factor authentication turned on or off and |
| 1111 | recovery codes made or used, personal access tokens created, deleted or |
| 1112 | given new scopes, SSH keys added or removed, and applications authorized, |
| 1113 | changed or revoked. Changes g1t staff made, such as removing an address |
| 1114 | someone else needed, say so and why. |
| 1115 | |
| 1116 | Token, SSH key, application and two-factor changes are also recorded in the |
| 1117 | [audit log](/guides/audit-log/) of each workspace you belong to, where its |
| 1118 | owners see them. |
| 1119 | |
| 1120 | ## Deleting your account |
| 1121 | |
| 1122 | You can delete your account from |
| 1123 | [Settings → Account](https://g1t.sh/settings/account), signed in as |
| 1124 | yourself. It is not gone at once: for **30 days** g1t keeps it, so that a |
| 1125 | deletion you did not mean, or did not make, can be undone through support. |
| 1126 | After 30 days it is removed for good. |
| 1127 | |
| 1128 | 1. Open **Settings → Account** and go to **Danger zone**. If anything is |
| 1129 | in the way, it says what, instead of offering the button. |
| 1130 | 2. Choose **Delete account**. The dialog lists what goes with it: your |
| 1131 | workspaces, the repositories you were added to, your access tokens, SSH |
| 1132 | keys and connected applications. |
| 1133 | 3. Type your username, and your password unless you signed in within the |
| 1134 | last 10 minutes. An account that signs in with GitHub only signs out, |
| 1135 | signs in with GitHub again, and deletes it within 10 minutes. |
| 1136 | 4. Choose **Delete account** again. You are signed out, and g1t emails your |
| 1137 | primary and backup addresses to say it was deleted. |
| 1138 | |
| 1139 | There is no API route or MCP tool for deleting an account, by design: like |
| 1140 | [creating one](#creating-an-account), it happens only in a browser, signed |
| 1141 | in as yourself, never with a token or as an agent. |
| 1142 | |
| 1143 | ### What stands in the way |
| 1144 | |
| 1145 | | | | |
| 1146 | | --- | --- | |
| 1147 | | A workspace you own alone | Each live workspace where you are the only owner is listed. [Make someone else an owner](/guides/workspaces/#change-someones-role) of it, or [delete it](/guides/workspaces/#delete-a-workspace), first. Deleting a workspace settles its billing, which can ask for something first: the list says what. A workspace you own with someone else is not in the way. | |
| 1148 | | A protected account | `g1t` and the other names g1t uses for itself can never be deleted, by anyone. | |
| 1149 | |
| 1150 | Billing belongs to workspaces, not to accounts, so once no workspace |
| 1151 | depends on you alone there is nothing for billing to settle. |
| 1152 | |
| 1153 | When g1t's staff delete an account, on its owner's request or for abuse, |
| 1154 | the workspaces it alone owns are not left without an owner. Staff either |
| 1155 | wait for another owner to be made, or delete those workspaces together |
| 1156 | with the account, each exactly as its owner would: its billing is settled |
| 1157 | first, everything in it goes with it, and it is kept 30 days for a |
| 1158 | restore like any deleted workspace. Its audit log records the deletion as |
| 1159 | g1t's staff. Staff never do this for a workspace whose billing cannot be |
| 1160 | settled yet (an unpaid invoice, prepaid credit, usage still being metered), |
| 1161 | or for one of the workspaces g1t protects; if any of them stands in the |
| 1162 | way, nothing is deleted. |
| 1163 | |
| 1164 | ### What happens |
| 1165 | |
| 1166 | At once, when you delete it: |
| 1167 | |
| 1168 | | | | |
| 1169 | | --- | --- | |
| 1170 | | Signing in | You are signed out everywhere. Signing in with your password, GitHub, a recovery code or from a tool fails, with the same answer a wrong password gets. | |
| 1171 | | Access tokens, SSH keys and applications | Your personal access tokens (classic and fine-grained), SSH keys, connected applications and sign-ins from a tool stop working and are removed, and so do the deploy keys you added to repositories. A workspace's own tokens are not affected, even ones you made. | |
| 1172 | | Workspaces, teams and repositories | You leave every workspace and team, and lose the roles you were given on single repositories. Repository invitations waiting for you are withdrawn, and invites you made that nobody used are revoked. | |
| 1173 | | Your profile | `g1t.sh/<username>` answers 404, and you drop out of search. Nobody can add you to a workspace, team or repository, and nothing more is emailed to you. | |
| 1174 | | What you wrote | Stays where it is, under your username for now. Commits made with your confirmed or noreply addresses show as `ghost`, and as yours again if your account is restored. | |
| 1175 | | Your username | Held for your account. Nobody else can take it. | |
| 1176 | |
| 1177 | Within 30 days, support can restore it: write to support@g1t.sh from one |
| 1178 | of its addresses. You come back to the workspaces, teams and repositories |
| 1179 | you were in, where they are still there, and sign in again with your |
| 1180 | password. Your old sessions, tokens and keys stay ended: make new ones. |
| 1181 | |
| 1182 | After 30 days it is removed for good: |
| 1183 | |
| 1184 | | | | |
| 1185 | | --- | --- | |
| 1186 | | Your addresses, keys and profile | Removed: your email addresses, two-factor secret and recovery codes, GitHub link, picture, profile and security log, and your inbox and its settings. | |
| 1187 | | What you wrote | Issues, pull requests, comments and reviews keep their place and their words, and show as written by `ghost`. You are taken off issues and pull requests you were assigned to or asked to review. Commits keep the name and address git recorded in them; those made with your [noreply address](#keeping-your-address-private) show as `ghost`. | |
| 1188 | | Workspaces you made | Name `ghost` as their creator. | |
| 1189 | | Statements, invoices and audit logs | Kept with your username, for the workspaces they belong to. | |
| 1190 | | Your username | Never given to another account or workspace, so links, mentions and remotes that use it keep meaning what they meant. `ghost` is reserved for this, and nobody can register it. | |
| 1191 | |
| 1192 | ## What g1t stores |
| 1193 | |
| 1194 | Passwords are stored as salted PBKDF2-SHA256 hashes. Sessions and tokens are |
| 1195 | stored as SHA-256 hashes. Neither can be read back. A two-factor secret is |
| 1196 | encrypted (AES-256-GCM) and bound to your account, and recovery codes are |
| 1197 | kept as SHA-256 hashes. |