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