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