| 1 | --- |
| 2 | title: Workspaces |
| 3 | description: Workspaces, their names and icons, renaming and deleting one, members, owners and the roles that add to a member, inviting people, Workspace mode's settings pages, requiring two-factor authentication, and access tokens that belong to a workspace. |
| 4 | --- |
| 5 | |
| 6 | A workspace owns repositories and is the first part of their address: |
| 7 | `g1t.sh/<workspace>/<repo>`. There is one kind. A workspace for just you and |
| 8 | one for a company are the same thing with a different number of members, so |
| 9 | there is no separate notion of an organization. |
| 10 | |
| 11 | ## Create a workspace |
| 12 | |
| 13 | Your account does not own repositories itself: a workspace does, and |
| 14 | repositories go in it. Every new account gets a workspace of its own, named |
| 15 | for its username and on the free plan, unless its invite brings it into |
| 16 | someone else's workspace; see |
| 17 | [your first workspace](/guides/authentication/#your-first-workspace). |
| 18 | Signed in without a workspace, g1t shows **Create your workspace or ask to |
| 19 | join one** in place of Mission control: the invitations waiting for you, |
| 20 | and the form below. |
| 21 | |
| 22 | To create another: |
| 23 | |
| 24 | 1. Open [g1t.sh/workspaces/new](https://g1t.sh/workspaces/new). |
| 25 | 2. Choose its name in URLs: lowercase letters, digits and single hyphens. |
| 26 | An owner can [change it later](#rename-a-workspace), and old addresses |
| 27 | redirect for 90 days. |
| 28 | 3. Optionally give it a display name. |
| 29 | |
| 30 | From the API, `POST /workspaces` with `slug` and `name`, or the |
| 31 | `workspace` tool's `create` action: |
| 32 | |
| 33 | ```sh |
| 34 | curl -X POST https://api.g1t.sh/workspaces \ |
| 35 | -H "Authorization: Bearer $G1T_TOKEN" \ |
| 36 | -H "Content-Type: application/json" \ |
| 37 | -d '{"slug": "acme", "name": "Acme"}' |
| 38 | ``` |
| 39 | |
| 40 | You can belong to up to ten workspaces. `GET /user`, or the `account` tool's `whoami` action, lists the |
| 41 | ones you belong to. |
| 42 | |
| 43 | A new workspace is free, and **each person can own one free workspace**. |
| 44 | While you own a free workspace, the page shows **You already own a free |
| 45 | workspace** in place of the form, with **Start the plan** on it; the API |
| 46 | answers `402` (`payment_required`). Start the plan on it, or delete it, |
| 47 | then create the new one. Several free workspaces from before are kept, but |
| 48 | each needs the plan (or deleting) before you can create another. See |
| 49 | [one free workspace per person](/guides/usage-and-billing/#one-free-workspace-per-person). |
| 50 | |
| 51 | Usernames and workspaces share one set of names, so a name means the same |
| 52 | thing wherever it appears. Your username is reserved for you: only you can |
| 53 | create a workspace with that name, and nobody can register a username that |
| 54 | is already a workspace. The names `g1t` and `g1t-agent` belong to |
| 55 | [g1t's agent](/guides/working-with-g1t/), and nobody can register them. |
| 56 | |
| 57 | ## Display name, slug and icon |
| 58 | |
| 59 | A workspace has two names: |
| 60 | |
| 61 | | | Example | Where it appears | Changes | |
| 62 | | --- | --- | --- | --- | |
| 63 | | **Display name** | `Flagon Industries` | The sidebar, the top of its page, mission control and link previews | Any time, up to 80 characters; spaces and capitals are fine | |
| 64 | | **Slug** | `flagon` | Every address: `g1t.sh/flagon/<repo>`, clone URLs, API paths and `g1t.page` app addresses | By an owner, once a day at most; the old one redirects for 90 days. See [rename a workspace](#rename-a-workspace) | |
| 65 | |
| 66 | Without a display name, the slug is shown. Where an address is shown, the |
| 67 | slug is in monospace beside the name. Owners change the display name and |
| 68 | description (up to 160 characters) on **Settings → General**, or with |
| 69 | [`PATCH /workspaces/{workspace}`](/reference/api/workspaces/update-workspace/) |
| 70 | (MCP: `workspace` `update`), which takes `name` and `description` and |
| 71 | changes only the fields given. It needs the `workspace:admin` scope, and |
| 72 | is recorded in the [audit log](/guides/audit-log/): |
| 73 | |
| 74 | ```sh |
| 75 | curl -X PATCH https://api.g1t.sh/workspaces/flagon \n -H "Authorization: Bearer $G1T_TOKEN" \n -H "Content-Type: application/json" \n -d '{"name": "Flagon Industries", "description": "Rockets, and the software that flies them."}' |
| 76 | ``` |
| 77 | |
| 78 | Neither changes the slug; that is a [rename](#rename-a-workspace). |
| 79 | |
| 80 | A workspace also has an icon. Without |
| 81 | one, g1t draws its first letter in a colour of its own. To upload one, an |
| 82 | owner opens **Settings → General** and picks an image: |
| 83 | |
| 84 | - PNG, JPEG, WebP or GIF, at most 1 MB. Square images look best. |
| 85 | - An image is checked by its contents, not its name. SVG is refused, |
| 86 | because it can carry script. |
| 87 | - **Remove** goes back to the letter. |
| 88 | |
| 89 | The icon then shows wherever the workspace does, and on its link previews |
| 90 | (PNG and JPEG icons only). Each image is served from |
| 91 | `g1tusercontent.com/avatars/<sha256>`, an address named after its contents, so an icon |
| 92 | that changes gets a new address and nothing shows the old one. |
| 93 | |
| 94 | You can upload a picture of yourself the same way, under |
| 95 | [Settings → Profile](https://g1t.sh/settings/profile). |
| 96 | |
| 97 | ## Rename a workspace |
| 98 | |
| 99 | Renaming changes the slug, the first part of every address under the |
| 100 | workspace. The display name is separate; change it on its own under |
| 101 | **Settings → General → Workspace details**. Only owners can rename a |
| 102 | workspace. |
| 103 | |
| 104 | 1. Open the workspace's **Settings → General** and go to **Address**. |
| 105 | 2. Type the new slug. The field shows the new address, `g1t.sh/<new>`, and |
| 106 | whether the name is available. |
| 107 | 3. Choose **Change address**, read what changes, type the new slug to |
| 108 | confirm, and choose **Change address** again. |
| 109 | |
| 110 | You land on the workspace's settings at its new address. Repositories, |
| 111 | issues and the rest move with it within a few seconds. |
| 112 | |
| 113 | ### What changes |
| 114 | |
| 115 | | | Before | After | |
| 116 | | --- | --- | --- | |
| 117 | | Pages | `g1t.sh/old/<repo>` | `g1t.sh/new/<repo>` | |
| 118 | | Git remotes | `https://g1t.sh/old/<repo>.git` | `https://g1t.sh/new/<repo>.git` | |
| 119 | | API paths | `https://api.g1t.sh/repos/old/<repo>` | `https://api.g1t.sh/repos/new/<repo>` | |
| 120 | | MCP tool arguments | `"owner": "old"` | `"owner": "new"` | |
| 121 | | Production apps | `https://<project>-old.g1t.page` | `https://<project>-new.g1t.page` | |
| 122 | | Previews | `https://<project>-git-<branch>-old.g1t.page` | `https://<project>-git-<branch>-new.g1t.page` | |
| 123 | |
| 124 | These stay the same: the display name, description and icon, members and |
| 125 | roles, access tokens, secrets and variables, integrations, webhooks, |
| 126 | issues and pull requests, and billing, plans and credit. |
| 127 | |
| 128 | ### What redirects, and for how long |
| 129 | |
| 130 | For 90 days after a rename, the old name keeps working: |
| 131 | |
| 132 | | | Behaviour | |
| 133 | | --- | --- | |
| 134 | | Web pages | Answer with a permanent redirect (301) to the same page under the new name, query string included. | |
| 135 | | `git clone`, `fetch`, `pull` and `push` | Redirected to the new remote. Git follows it, but prints a warning each time until you update the remote. | |
| 136 | | API and MCP | A call that names the old slug runs under the new one. | |
| 137 | | `g1t.page` apps | Production and preview addresses under the old name redirect to the new ones. | |
| 138 | |
| 139 | Update your remotes now rather than relying on the redirect: |
| 140 | |
| 141 | ```sh |
| 142 | git remote set-url origin https://g1t.sh/<new>/<repo>.git |
| 143 | ``` |
| 144 | |
| 145 | Update anything else that has the old name written into it, too: links in |
| 146 | READMEs and docs, CI configuration, API clients and MCP clients. |
| 147 | |
| 148 | ### Limits |
| 149 | |
| 150 | - A workspace can be renamed once every 24 hours. |
| 151 | - For 90 days the old name is held for the workspace. Nobody else can take |
| 152 | it, and you can rename back to it. |
| 153 | - After 90 days the redirects stop, and anyone can create a workspace or |
| 154 | register a username with the old name. Links and remotes that still use |
| 155 | it then reach whatever has the name, or nothing. |
| 156 | - The new name follows the same rules as a new workspace: lowercase letters, |
| 157 | digits and single hyphens, up to 39 characters, not a reserved word or a |
| 158 | well-known GitHub action owner's name (such as `actions` or `docker`), and |
| 159 | not another workspace's slug or someone else's username. |
| 160 | |
| 161 | ## Workspace aliases |
| 162 | |
| 163 | An alias is a second name for a workspace that leads to it for good, |
| 164 | wherever a workspace's name goes. On g1t.sh, `g1t` is an alias of |
| 165 | `flagon-io`, the workspace of Flagon, Inc., which builds g1t and holds its |
| 166 | repositories: `g1t.sh/g1t/deploy` is the repository `flagon-io/deploy`. |
| 167 | |
| 168 | | | Behaviour | |
| 169 | | --- | --- | |
| 170 | | Web pages | Answer with a permanent redirect (301) to the same page under the workspace's slug, query string included. | |
| 171 | | `git clone`, `fetch`, `pull` and `push` | Answered in place, as the repository under the workspace's slug, with the same permissions, and no redirect for git to warn about. | |
| 172 | | API and MCP | A call that names the alias runs under the workspace's slug, and the answer names the workspace by its slug. A token that reaches one repository reaches it under the alias too, and nothing else. | |
| 173 | | Packages | Registry addresses under the alias redirect to the workspace's. | |
| 174 | | Actions | `uses: g1t/deploy@v1` and `g1t/workflows/.g1t/workflows/deploy.yml@v1` are found as `flagon-io/deploy` and `flagon-io/workflows`. See [g1t's own actions](/guides/actions/#g1ts-own-actions). | |
| 175 | |
| 176 | An alias resolves whatever its case (`G1T` is `g1t`), and follows the |
| 177 | workspace through renames: it points at the workspace, not at its slug. |
| 178 | Pages, API answers and links always show the workspace's own slug. |
| 179 | |
| 180 | An alias never changes who can see what. A private repository is found |
| 181 | under the alias only by someone who could see it under the workspace's |
| 182 | slug, and the alias gives nobody access they did not have. |
| 183 | |
| 184 | Aliases are set and removed by g1t's staff; there is no setting for them. |
| 185 | While an alias exists, nobody can register it as a username, create a |
| 186 | workspace with it, or rename a workspace to it. An alias is never a |
| 187 | person's or a workspace's name, and never one of the site's own routes. |
| 188 | [Contact us](https://g1t.sh/support) if your workspace needs one, such as |
| 189 | for a name it used to trade under. |
| 190 | |
| 191 | ## Data residency |
| 192 | |
| 193 | Data residency says where the git data of the workspace's new repositories |
| 194 | is stored. The section appears in **Settings** once g1t can store |
| 195 | repositories in the EU. Until then it is not shown, and every repository is |
| 196 | stored wherever g1t stores repositories. |
| 197 | |
| 198 | | Setting | What it does | |
| 199 | | --- | --- | |
| 200 | | Anywhere | New repositories are stored wherever g1t stores repositories. The default. | |
| 201 | | EU only | New repositories are stored in the EU. If EU storage cannot take one right now, the repository is not made, and you are told why. It is never stored somewhere else instead. | |
| 202 | |
| 203 | To change it: |
| 204 | |
| 205 | 1. Open the workspace, then **Settings**. Only owners see the page. |
| 206 | 2. Under **Data residency**, choose **Anywhere** or **EU only**. |
| 207 | 3. Select **Save**. |
| 208 | |
| 209 | The setting applies to repositories made after you save it, however they |
| 210 | are made: from the site, with the API, by pushing to a new address, or by |
| 211 | importing. Repositories the workspace already has stay where they are. To |
| 212 | move them, contact support; a move keeps each repository's address, history |
| 213 | and settings, and pushes to it wait a few minutes while it happens. |
| 214 | |
| 215 | Data residency covers the git data: commits, branches, tags and files, |
| 216 | including pull requests' working copies, which are stored with their |
| 217 | repository. Issues, pull requests, comments and settings are not affected. |
| 218 | A repository [transferred](/guides/transferring-repositories/) to another |
| 219 | workspace stays where it is stored. |
| 220 | |
| 221 | Changing the setting is recorded in the |
| 222 | [audit log](/guides/audit-log/) as `workspace.residency_changed`. |
| 223 | |
| 224 | ## Delete a workspace |
| 225 | |
| 226 | Deleting a workspace takes everything in it with it, in one step: its |
| 227 | repositories, projects, apps, members' access and tokens. Only an owner can, |
| 228 | signed in as a person, typing the workspace's slug to confirm. |
| 229 | |
| 230 | It is not gone at once. For **30 days** g1t keeps all of it, so that a |
| 231 | deletion you did not mean, or did not make, can be undone: an owner writes |
| 232 | to support@g1t.sh, and support restores the workspace as it was. After 30 |
| 233 | days it is purged for good. |
| 234 | |
| 235 | 1. Open the workspace's **Settings → General** and go to **Danger zone**. |
| 236 | It lists what will go with the workspace: its repositories, projects, |
| 237 | live apps and members. |
| 238 | 2. Choose **Delete workspace**, read what happens, type the workspace's |
| 239 | slug to confirm, and choose **Delete workspace** again. You are taken |
| 240 | back to your own home. |
| 241 | |
| 242 | The one thing that can stand in the way is billing: see |
| 243 | [what billing needs](#what-billing-needs). Repositories you want to keep in |
| 244 | another workspace, [transfer](/guides/transferring-repositories/) first; |
| 245 | their old addresses keep redirecting after the workspace is gone. |
| 246 | |
| 247 | From the API, call |
| 248 | [`DELETE /workspaces/{workspace}`](/reference/api/workspaces/delete-workspace/) |
| 249 | with the slug in `confirm`; over MCP, the `workspace` tool's `delete` |
| 250 | action. |
| 251 | |
| 252 | Some workspaces can never be deleted, by anyone, such as Flagon's, which |
| 253 | runs g1t. Their Danger zone says so instead of offering the button. |
| 254 | |
| 255 | ### What billing needs |
| 256 | |
| 257 | | | | |
| 258 | | --- | --- | |
| 259 | | Money owed | Charged to the workspace's card at once, with no minimum charge. With no card, add one or pay from **Billing** first. | |
| 260 | | An unpaid invoice | Pay it from **Billing** first. | |
| 261 | | Prepaid credit | It would be lost: spend it, or write to support@g1t.sh about a refund, first. | |
| 262 | | Usage this month still being metered | Storage and git operations are charged when the month closes. You can delete the workspace from the 1st of next month. | |
| 263 | | The g1t plan | Ends at Stripe at once, not at the end of the period. | |
| 264 | | An enterprise account | A workspace billed through one is moved off it by g1t first: write to support@g1t.sh. | |
| 265 | |
| 266 | A comped workspace owes nothing; only its plan is ended. |
| 267 | |
| 268 | ### What happens |
| 269 | |
| 270 | At once, when an owner deletes it: |
| 271 | |
| 272 | | | | |
| 273 | | --- | --- | |
| 274 | | Members | Lose access, and the workspace leaves their list. Their own accounts are not touched: a person with no workspace left can still sign in, and create or join one. | |
| 275 | | Access tokens | The workspace's own tokens stop working. Personal tokens are not affected. | |
| 276 | | Repositories | Deleted with it: git refuses them, and their pages answer 404. Agents and workflow runs stop. Ones deleted on their own earlier stay deleted. | |
| 277 | | Projects and apps | Hidden. Its apps are taken offline and nothing builds. Custom domains are kept for a restore. | |
| 278 | | Its pages | Answer 404, and it drops out of search. | |
| 279 | | Billing | What it owes is charged, and its plan ends, as [billing needs](#what-billing-needs). Nothing more is charged. | |
| 280 | | The audit log | Records the deletion. | |
| 281 | |
| 282 | Within 30 days, support can restore it: its members, tokens, repositories, |
| 283 | projects and apps come back as they were, and its apps go back up as its |
| 284 | limit allows. Its plan does not come back by itself: an owner starts it |
| 285 | again from **Billing**. A repository deleted on its own before the |
| 286 | workspace was stays in **Recently deleted**. |
| 287 | |
| 288 | After 30 days it is purged: |
| 289 | |
| 290 | | | | |
| 291 | | --- | --- | |
| 292 | | Repositories | Purged, their git data with them, including any that were in Recently deleted. | |
| 293 | | Projects, apps and custom domains | Removed. | |
| 294 | | Webhooks, integrations, secrets and variables | The workspace's own are removed. | |
| 295 | | Memory and guardrails | The workspace's own are removed. | |
| 296 | | Statements, invoices and the ledger | Kept, for accounting. | |
| 297 | | The audit log | Kept as [long as its account keeps it](/guides/audit-log/#how-long-it-is-kept), with the purge as its last entry: once the plan ends with the workspace, that is 7 days, unless an enterprise pays for it or longer was arranged. With no owners left, ask support@g1t.sh for an export. | |
| 298 | | Old addresses | Redirects for repositories transferred out keep working. The workspace's own pages answer 404. | |
| 299 | |
| 300 | ### The name afterwards |
| 301 | |
| 302 | A deleted workspace's slug is never given to another workspace or used as |
| 303 | someone else's username. While it can still be restored, the slug is held |
| 304 | for it. Links and git remotes that still use it keep |
| 305 | meaning what they meant: a transferred repository's old address keeps |
| 306 | redirecting to it, and nobody can take the name in the meantime. |
| 307 | |
| 308 | The one exception: when the slug is your own username, you may create a |
| 309 | workspace with that name again once the old one is purged. It starts empty, on standard billing terms, |
| 310 | and a repository made in it at an old address ends that address's redirect. |
| 311 | |
| 312 | ## Members and roles |
| 313 | |
| 314 | <a id="members-and-owners"></a> |
| 315 | |
| 316 | | Role | Can | |
| 317 | | --- | --- | |
| 318 | | Member | Create repositories (as the [member privileges](#member-privileges) allow), see the workspace's usage and billing, and get the workspace's [base permission](/guides/access-and-roles/#the-base-permission) on every repository in it: Read for a new workspace, which an owner can raise to Write to let members push, merge pull requests, plan work and put g1t to work. Admin on the repositories they create. | |
| 319 | | Owner | Everything a member can, and manage members and owners, the base permission, the member privileges, two-factor requirement, the workspace's access tokens, its details, and billing: the plan, card checks, prepayment and limits. Admin on every repository, and the only ones who can transfer and delete them unless the member privileges allow admins; see [access and roles](/guides/access-and-roles/). | |
| 320 | |
| 321 | A workspace can have any number of owners, and always has at least one. |
| 322 | |
| 323 | ### Roles that add to a member |
| 324 | |
| 325 | An owner can give a member one or both of these roles. Each adds to what |
| 326 | the member already has; an owner has both already. |
| 327 | |
| 328 | | Role | Adds | |
| 329 | | --- | --- | |
| 330 | | **Billing manager** | Manages the workspace's billing as an owner does: the plan, budget and spend limit, AI credit and auto-reload, the card, billing details and invoices. Gives nothing on repositories. | |
| 331 | | **Security manager** | Read on every repository, and seeing and managing every security alert and security setting on them: dismissing and reopening alerts, custom patterns, reviewing push protection bypass requests, and the workspace's security settings. | |
| 332 | |
| 333 | Neither passes to an agent working for the person. |
| 334 | |
| 335 | ### Change someone's role |
| 336 | |
| 337 | On **Members**, `g1t.sh/<workspace>/-/members` (**Workspace → Access → |
| 338 | Members**), an owner opens the **⋯** menu beside a member: |
| 339 | |
| 340 | 1. **Make owner** or **Make member** changes their role. |
| 341 | 2. **Billing manager** and **Security manager** turn each role on or off. |
| 342 | 3. **Transfer ownership…** hands the workspace to that member: they become |
| 343 | an owner and you a member, in one step. To add an owner without stepping |
| 344 | down, choose **Make owner** instead. |
| 345 | 4. **Remove from {workspace}…** takes them out. Their roles on its |
| 346 | repositories and their place in its teams go too. |
| 347 | |
| 348 | Owners see a shield beside each member: green when two-factor |
| 349 | authentication is on, amber when it is off. Above the list, a search box |
| 350 | finds a member by username or name, and the filters narrow the list by |
| 351 | role, by two-factor authentication (owners only) and by team; each is kept |
| 352 | in the address (`?q=`, `?role=`, `?2fa=`, `?team=`), so a filtered list can |
| 353 | be shared. |
| 354 | |
| 355 | The last owner cannot be made a member, removed, or leave: make someone |
| 356 | else an owner first, or [delete the workspace](#delete-a-workspace). |
| 357 | |
| 358 | ### Leave a workspace |
| 359 | |
| 360 | Anyone can leave a workspace they belong to: at the bottom of **Members**, |
| 361 | choose **Leave {workspace}** and confirm. Your roles on its repositories |
| 362 | and your place in its teams go with you at once. The only owner cannot |
| 363 | leave. |
| 364 | |
| 365 | ### Add people |
| 366 | |
| 367 | Whoever creates a workspace is its owner. Nobody is added to a workspace |
| 368 | without saying yes: an owner invites people, and each person accepts or |
| 369 | declines. |
| 370 | |
| 371 | Anyone can make a g1t account without an invite, so to bring someone in |
| 372 | you invite them to the workspace; someone without an account signs up from |
| 373 | the invitation. |
| 374 | |
| 375 | On the workspace's **Members** page, `g1t.sh/<workspace>/-/members` |
| 376 | (**Workspace → Access → Members** in the sidebar), or on **Invitations** |
| 377 | beside it: |
| 378 | |
| 379 | 1. Select **Invite**. A dialog opens. |
| 380 | 2. Under **Who**, type a username, a name or an email address. As you |
| 381 | type, people on g1t are offered by username and name, with their |
| 382 | pictures; hover over one for their card. Only usernames, names and |
| 383 | pictures are shown, never anyone's email address. An email address is |
| 384 | taken as written. |
| 385 | 3. Choose the **Role** they join with: **Member** or **Owner**. |
| 386 | 4. Write a **Message** if you like: a line quoted in the invitation email, |
| 387 | under your name. Up to 500 characters. |
| 388 | 5. Select **Invite**. The dialog closes and the page says who was invited. |
| 389 | |
| 390 | - **By username**: they get a |
| 391 | [workspace invitation](/guides/authentication/#workspace-invitations) in |
| 392 | their notifications and by email, and join with that role when they accept at |
| 393 | [g1t.sh/invitations](https://g1t.sh/invitations). If they decline, you |
| 394 | are told in your notifications. It costs nothing. |
| 395 | - **By email address**: g1t emails an invite that only that address can |
| 396 | use. With a g1t account, it is a workspace invitation like the one above |
| 397 | and costs nothing. Without one, the invitation also lets them make the |
| 398 | account first, and costs nothing (see |
| 399 | [invites](/guides/authentication/#invites)). The new account is then |
| 400 | invited to the workspace, and joins when it accepts. The page never says which it was. |
| 401 | |
| 402 | The email names you and the workspace and links to the invite's page. |
| 403 | Someone new signs up right there, with the invited address filled in; once |
| 404 | the address is confirmed (straight away when they opened the page from |
| 405 | that email, which proves the address is theirs, otherwise with the code g1t |
| 406 | emails them), they are asked to accept or decline the invitation. Someone |
| 407 | with an account signs in and accepts on the page. Accepting lands them in |
| 408 | the workspace, with a one-time welcome. See |
| 409 | [using an invite](/guides/authentication/#using-an-invite). |
| 410 | |
| 411 | #### When someone joins |
| 412 | |
| 413 | The moment a person becomes a member, by accepting an invitation or by |
| 414 | using an invite code that names the workspace, the workspace's |
| 415 | [@g1t](/guides/agents/#after-that) opens its direct message with them in |
| 416 | Chat and says a short welcome: who it is, what they can ask it, that |
| 417 | agents answer in a direct message and when @mentioned in a channel, and |
| 418 | where Home, Chat, Code and Artifacts are. It is the only time an agent |
| 419 | speaks first, it happens once per person per workspace, and whoever |
| 420 | created the workspace gets none. The welcome is a reply like any other, |
| 421 | charged to @g1t's budget; with no model the workspace can use, it is a |
| 422 | short fixed message. The join is also an event, `workspace.member_joined`, |
| 423 | for the workspace's [webhooks](/guides/webhooks/#events). |
| 424 | |
| 425 | Every invitation sent is on **Invitations**, |
| 426 | `g1t.sh/<workspace>/-/members/invitations` (**Workspace → Access → |
| 427 | Invitations**, owners only): a table of who it is for, who sent it, the |
| 428 | role, when it was sent and where it stands, newest first. The chips above |
| 429 | it narrow the table, each with its count: |
| 430 | |
| 431 | | Chip | Shows | |
| 432 | | --- | --- | |
| 433 | | **All** | Every invitation, however it ended. | |
| 434 | | **Pending** | The ones still waiting: to be used, for the new account to confirm its email, or for the person to accept. Each says the day it stops working (30 days after it was sent). | |
| 435 | | **Accepted** | The people who joined. | |
| 436 | | **Declined** | The people who said no. | |
| 437 | | **Expired** | The ones nobody used in time. g1t does not yet know whether an invitation's email was delivered, so one that bounced ends up here too. | |
| 438 | | **Revoked** | The ones an owner took back. | |
| 439 | |
| 440 | The **⋯** menu on a pending invitation has **Copy link** (the invitation's |
| 441 | page, while it waits to be used), **Send again** (the same email, and the |
| 442 | inbox notice again for someone on g1t; the invitation itself does not |
| 443 | change) and **Revoke**. Through the API, the invitation is sent again with |
| 444 | nothing yet; revoke it and invite again instead. Converting an outside |
| 445 | collaborator to a member sends them an invitation the same way. The |
| 446 | Members page says how many invitations are waiting, and leads here. |
| 447 | Through the API, use |
| 448 | [`POST /workspaces/{workspace}/invitations`](/reference/api/invites/invite-member/) |
| 449 | with a `username` or an `email` and a `role` (the `workspace` tool's |
| 450 | `invite_member` action over MCP); the person answers with |
| 451 | [`POST /user/invitations/{id}/accept`](/reference/api/invites/accept-invitation/) |
| 452 | or [`/decline`](/reference/api/invites/decline-invitation/). |
| 453 | |
| 454 | To give someone a role on one repository without making them a member, |
| 455 | add them as an [outside collaborator](/guides/access-and-roles/#outside-collaborators). |
| 456 | |
| 457 | **A free workspace cannot add people.** Until it starts the g1t plan, it |
| 458 | cannot add members, send invites, or invite outside collaborators, and an |
| 459 | invite sent before waits until the plan is on. Its members stay. Members and |
| 460 | Invitations show **Start the plan to invite people** with the button in place of |
| 461 | **Invite**, and the API and MCP answer `402` (`payment_required`). See |
| 462 | [who a free workspace can add](/guides/usage-and-billing/#who-a-free-workspace-can-add). |
| 463 | |
| 464 | ### Members through the API |
| 465 | |
| 466 | | Route | MCP tool and action | What it does | Who | |
| 467 | | --- | --- | --- | --- | |
| 468 | | `GET /workspaces/{workspace}/members` | `workspace` `list_members` | Its members, owners first: `role` (`owner` or `member`), `org_roles` (`billing_manager`, `security_manager`) and, for owners, `two_factor`. | Members | |
| 469 | | `PATCH /workspaces/{workspace}/members/{username}` | `workspace` `update_member` | Change `role` and `org_roles` (a list that replaces theirs). | Owners | |
| 470 | | `DELETE /workspaces/{workspace}/members/{username}` | `workspace` `remove_member` | Remove someone. Your own username is leaving. | Owners | |
| 471 | | `POST /workspaces/{workspace}/transfer_ownership` | `workspace` `transfer_ownership` | Hand it to `username`: they become an owner, you a member. | Owners | |
| 472 | | `DELETE /user/memberships/{workspace}` | `workspace` `leave` | Leave it. | You | |
| 473 | |
| 474 | Each is for people, signed in or with a personal access token; never an |
| 475 | agent. A change that would leave no owner answers `409`. |
| 476 | |
| 477 | ```sh |
| 478 | curl -X PATCH https://api.g1t.sh/workspaces/acme/members/grace \ |
| 479 | -H "Authorization: Bearer $G1T_TOKEN" \ |
| 480 | -d '{"org_roles": ["security_manager"]}' |
| 481 | ``` |
| 482 | |
| 483 | ## Member privileges |
| 484 | |
| 485 | What members can do beyond their role on each repository. Owners set them |
| 486 | under **Workspace → Access → [Permissions](/guides/permissions/#code)**, |
| 487 | `g1t.sh/<workspace>/-/permissions`, in the **Code** card, and can always do |
| 488 | all of it themselves. |
| 489 | |
| 490 | | Setting | Default | When on | |
| 491 | | --- | --- | --- | |
| 492 | | **Members can create public repositories** (`members_can_create_public_repositories`) | On | Any member can create a public repository. | |
| 493 | | **Members can create private repositories** (`members_can_create_private_repositories`) | On | Any member can create a private repository. | |
| 494 | | **Repository admins can change visibility** (`members_can_change_repo_visibility`) | On | A member with Admin on a repository can make it public or private, if they could create one of that kind. | |
| 495 | | **Repository admins can delete and transfer repositories** (`members_can_delete_repositories`) | Off | A member with Admin on a repository can delete it, or transfer it to a workspace where they can create one. | |
| 496 | | **Repository admins can add outside collaborators** (`members_can_invite_outside_collaborators`) | On | A member with Admin on a repository can give a role on it to someone outside the workspace. | |
| 497 | |
| 498 | When one is off, only owners can do it; the refusal says so. Someone who is |
| 499 | not a member, an outside collaborator with Admin, never gets these. |
| 500 | Forking private repositories is not a setting: g1t has no personal forks |
| 501 | to allow or refuse. |
| 502 | |
| 503 | Through the API, `GET /workspaces/{workspace}` returns each by its name, |
| 504 | and [`PATCH /workspaces/{workspace}`](/reference/api/workspaces/update-workspace/) |
| 505 | sets any of them (`workspace` `update` over MCP). Each change is in the |
| 506 | [audit log](/guides/audit-log/) as `workspace.member_privileges_changed`. |
| 507 | |
| 508 | ## Workflows the workspace manages |
| 509 | |
| 510 | An owner can run a workflow in every repository of the workspace, or in |
| 511 | those whose names match, without committing it to each: a security scan, a |
| 512 | licence check, a release policy. Add it under **Workspace → Code → |
| 513 | Actions**, `g1t.sh/<workspace>/-/actions`, from a workflow file in one of |
| 514 | the workspace's repositories, as **Required** (repositories cannot take its |
| 515 | place or turn it off, so a ruleset can require its check) or **Default** |
| 516 | (a repository's own workflow of the same name runs instead, and its admins |
| 517 | can turn it off). Each repository's Actions page lists it as managed by the |
| 518 | workspace. [Workflows a workspace manages](/guides/actions/#workflows-a-workspace-manages) |
| 519 | has the details, and the API. |
| 520 | |
| 521 | ## Require two-factor authentication |
| 522 | |
| 523 | An owner can require everyone with access to the workspace, its members |
| 524 | and its outside collaborators, to have |
| 525 | [two-factor authentication](/guides/authentication/#two-factor-authentication) |
| 526 | on. |
| 527 | |
| 528 | 1. Turn it on for your own account first. |
| 529 | 2. Open **Workspace → General**, `g1t.sh/<workspace>/-/settings#two-factor`. |
| 530 | Under **Authentication security**, it says how many members do not have |
| 531 | it on, and who. |
| 532 | 3. Turn on **Require two-factor authentication** and choose **Save**. |
| 533 | |
| 534 | From then on, someone without it keeps their place but cannot use the |
| 535 | workspace: its private repositories, pages and API answer as if they were |
| 536 | not a member, and every page shows them a notice with a link to turn it |
| 537 | on. Turning it on gives everything back at once. Nobody can join or accept |
| 538 | an invitation to the workspace without it. |
| 539 | |
| 540 | Through the API, `two_factor_requirement_enabled` on |
| 541 | `PATCH /workspaces/{workspace}`. Recorded as `workspace.two_factor_required` |
| 542 | and `workspace.two_factor_not_required`. |
| 543 | |
| 544 | ## The workspace's page |
| 545 | |
| 546 | A workspace's own page, `g1t.sh/<workspace>`, has its icon, name, address |
| 547 | and description at the top, then its overview: your |
| 548 | [pinned projects](#pinned-and-recent-projects), then the most active ones, |
| 549 | the pull requests in progress across them, and **All projects**. Members |
| 550 | also see a **Usage** card with this month's spend, and who belongs. |
| 551 | |
| 552 | The workspace's other pages each have a heading of their own and a row in |
| 553 | [the sidebar](#the-sidebar), lit while you are on them. The trail in the |
| 554 | top bar, such as *acme / Projects*, leads back to the workspace's page. |
| 555 | |
| 556 | | Page | Address | Who | | |
| 557 | | --- | --- | --- | --- | |
| 558 | | **Overview** | `g1t.sh/<workspace>` | Everyone | The page above. | |
| 559 | | **Projects** | `/-/projects` | Everyone | Every project you can see. See [the Projects page](#the-projects-page). | |
| 560 | | [**Packages**](/guides/packages/) | `/-/packages` | Everyone | What the workspace publishes. A visitor opens it from **Packages** on the workspace's page. | |
| 561 | | [**Teams**](/guides/teams/) | `/-/teams` | Members | Groups of members given roles on repositories together, mentioned as `@workspace/team` and asked to review together. Each team has its own page at `/-/teams/<team>`. | |
| 562 | | [**People**](/guides/people-and-teams/) | `/-/people` | Members | The workspace's people, with their titles, teams and what they own. Each has a profile at `/-/people/<username>`. Agents are not in it; an agent's page is `/-/agents/<handle>`. | |
| 563 | | **Members and invites** | `/-/members` | Members | Who belongs. Owners invite, change roles and remove people here. | |
| 564 | | **Insights** | `/-/insights` | Members | Coming soon: how the whole workspace delivers. | |
| 565 | | **Settings** | `/-/settings` | Owners | How the workspace is set up and connected (below). | |
| 566 | |
| 567 | Each person sees the projects they can read: a member whose base permission |
| 568 | is None, an [outside collaborator](/guides/access-and-roles/#outside-collaborators) |
| 569 | or a visitor sees the public ones and those shared with them, without the |
| 570 | workspace's people, deployments or settings. |
| 571 | |
| 572 | `g1t.sh/<workspace>?tab=projects` (or `repositories`, `packages`, |
| 573 | `teams`, `people`, `members`, `insights` or `settings`) opens that page. |
| 574 | |
| 575 | ### The Projects page |
| 576 | |
| 577 | The Projects page, `g1t.sh/<workspace>/-/projects`, is made for workspaces with hundreds of projects: |
| 578 | |
| 579 | - **Find a project** matches every word you type in a project's name, its |
| 580 | address or its description. Press <kbd>/</kbd> anywhere on the page to |
| 581 | start typing. |
| 582 | - **Filters**: public or private; [what it is](/guides/projects/#what-a-project-is) |
| 583 | (apps, libraries, and tools, docs or other when the workspace has any); the language its |
| 584 | manifests say it is written in; only projects with |
| 585 | [Deployments](/guides/deployments/) on; and archived projects, which are |
| 586 | left out unless you ask for them. Each choice shows how many projects it |
| 587 | holds. |
| 588 | - **Sort** by recently updated (its settings or its last push, whichever is |
| 589 | later), recently pushed, most active, or name. Most active counts each |
| 590 | push, issue or pull request opened or closed, review, comment and |
| 591 | deployment, and what happened a week ago counts half as much. |
| 592 | - **List** or **grid**, 30 projects to a page. |
| 593 | - The arrow keys (or <kbd>j</kbd> and <kbd>k</kbd>) move between projects, |
| 594 | and <kbd>Enter</kbd> opens one. |
| 595 | |
| 596 | Everything you choose is in the address, so a filtered list can be |
| 597 | bookmarked or shared. |
| 598 | |
| 599 | ## The rail, the sidebar and the page |
| 600 | |
| 601 | Signed in, g1t is always about one workspace: the one you are in. On a |
| 602 | workspace's pages, and on a project in one of your workspaces, that is the |
| 603 | workspace the page belongs to; anywhere else, even on public pages such as |
| 604 | [Explore](https://g1t.sh/explore), someone's profile or another |
| 605 | workspace's public project, it stays the one you chose last. |
| 606 | |
| 607 | Each page has three parts: |
| 608 | |
| 609 | | Part | Where | What it holds | |
| 610 | | --- | --- | --- | |
| 611 | | **The rail** | A narrow column of icons down the left edge | g1t's mark, which goes to [Home](/guides/home/); the built-in apps; the apps you pinned; **Apps**; and at its foot **People**, **Workspace** and your account. Hold the pointer over an icon for its name. | |
| 612 | | **The sidebar** | Flush against the rail | The workspace and its switcher at the top, **Search or jump to**, then the lists of the app you are in, in named groups. Home and Apps have none. | |
| 613 | | **The page** | The rest of the window, flat against the sidebar | Its header: the button that shows or hides the sidebar, where you are, **Search or jump to** (<kbd>Ctrl</kbd> <kbd>K</kbd>, or <kbd>⌘</kbd> <kbd>K</kbd> on a Mac) when the sidebar is hidden or has a search of its own, [your spend this month](/guides/spend/#in-the-top-bar), **Ask g1t**, the [notifications](/guides/notifications/) bell and **Create new**. Then the page itself. | |
| 614 | |
| 615 | ### The rail |
| 616 | |
| 617 | The built-in apps are always in the rail, each an icon with what is |
| 618 | unread on it: |
| 619 | |
| 620 | | App | Opens | |
| 621 | | --- | --- | |
| 622 | | **Home** | Where you're needed across the workspace, and what happened while you were away. See [Home](/guides/home/). | |
| 623 | | **Chat** | Channels and messages. See [Chat](/guides/chat/). | |
| 624 | | **Notifications** | Reviews, mentions, failures and what agents wait on. See [notifications](/guides/notifications/). | |
| 625 | | **Code** | Projects, pull requests and checks. Not shown to a member without [Code access](/guides/agent-access/). | |
| 626 | | **Agents** | The workspace's agents and their sessions, and how they are set up. See [agents](/guides/agents/). | |
| 627 | | **Artifacts** | Documents, decks and pages. See [artifacts](/guides/artifacts/). | |
| 628 | | **People** | Everyone in the workspace (its people; agents are under Agents); and its [teams](/guides/teams/), which agents can be on. See [people and teams](/guides/people-and-teams/). | |
| 629 | | **Workspace** | The workspace's settings: who has access, money, compute, and how each part of g1t is set up. See [Workspace mode](#workspace-mode). | |
| 630 | |
| 631 | The app you are in sits on a filled square. Your account is the |
| 632 | avatar at the foot: your status, your profile and settings, |
| 633 | [appearance](#appearance), the documentation, support, status, the |
| 634 | keyboard's shortcuts, and signing out. |
| 635 | |
| 636 | ### Appearance |
| 637 | |
| 638 | g1t comes in a dark theme and a light one. Until you choose, it follows |
| 639 | your system's setting. |
| 640 | |
| 641 | | Choice | What you see | |
| 642 | | --- | --- | |
| 643 | | **Auto** | Follows your system's light or dark setting, and changes when it does. | |
| 644 | | **Light** | A near-white page with white panels and a deeper lavender accent. | |
| 645 | | **Dark** | g1t's very dark gray with the lavender accent. | |
| 646 | |
| 647 | To change it: |
| 648 | |
| 649 | 1. Select your avatar at the foot of the rail. On a phone, open **More**, |
| 650 | then **You and help**. |
| 651 | 2. Under **Appearance**, select **Auto** (the screen icon), **Light** (the |
| 652 | sun) or **Dark** (the moon). |
| 653 | |
| 654 | The page changes at once. You can also choose under |
| 655 | [Settings → Account](https://g1t.sh/settings/account), or press |
| 656 | <kbd>Ctrl</kbd> <kbd>K</kbd> (<kbd>⌘</kbd> <kbd>K</kbd> on a Mac) and run |
| 657 | **Use light theme**, **Use dark theme** or **Use auto theme**. Signed out, |
| 658 | the same commands are in ⌘K, and the phone's menu has the switch. |
| 659 | |
| 660 | Your choice is kept in this browser, in a `g1t_theme` cookie, so every page |
| 661 | is drawn in it from the start; another browser or device starts on Auto. |
| 662 | Product screenshots on g1t.sh's home page, and the g1t mark on agents' |
| 663 | avatars, stay dark in either theme. |
| 664 | |
| 665 | These docs and [status.g1t.sh](https://status.g1t.sh/) also follow your |
| 666 | system's setting, each with its own switch for this browser: here, the |
| 667 | **Auto**, **Light** and **Dark** menu at the end of the header (at the foot |
| 668 | of the menu on a phone); on the status page, the three icons at the top. |
| 669 | |
| 670 | ### Apps |
| 671 | |
| 672 | Apps are what the workspace connected in [Customize](/guides/customize/) |
| 673 | that you can use: the integrations it connected, such as Sentry or GitHub, |
| 674 | each opening its own page. An app you can't use shows **Request access**. |
| 675 | The built-in apps' own pages are in their sidebars, not in Apps: Code's has |
| 676 | **Projects**, **Security** and **Packages**; Agents' has **Templates**, |
| 677 | **Context** and **Memory**; People's has **Everyone**, **Teams** and **Org |
| 678 | chart**; Workspace's has every settings page, from **Members** to the |
| 679 | **Audit log** (see [Workspace mode](#workspace-mode)). |
| 680 | |
| 681 | A pinned app shows as its mark under the built-in ones, in the order you |
| 682 | pinned them. To pin one: |
| 683 | |
| 684 | 1. Select **Apps** near the foot of the rail, or open the Apps page at |
| 685 | `g1t.sh/<workspace>/-/apps`. |
| 686 | 2. Find the app, by name if you like. |
| 687 | 3. Select the pin on its tile. Select it again to unpin it. |
| 688 | |
| 689 | When the workspace hasn't added anything yet, the launcher and the Apps |
| 690 | page say so and lead to Customize. The launcher's **Customize** link |
| 691 | always does, as does <kbd>Ctrl</kbd> <kbd>K</kbd> and *Customize*. |
| 692 | |
| 693 | Your pins are yours alone and each workspace has its own. They are saved |
| 694 | to your account, so your rail is the same on every browser and device you |
| 695 | sign in on, in the order you pinned. |
| 696 | |
| 697 | ### The sidebar |
| 698 | |
| 699 | The sidebar's top row names the workspace you are in. Select it to switch |
| 700 | to another of your workspaces, make a new one, or open your profile or |
| 701 | settings. The button beside it hides the sidebar, leaving the rail alone |
| 702 | and the page wider, and the same button at the left of the page's header |
| 703 | brings it back; <kbd>Ctrl</kbd> <kbd>B</kbd> (<kbd>⌘</kbd> <kbd>B</kbd> on |
| 704 | a Mac) does both, except while you type. g1t remembers which you chose. |
| 705 | When the sidebar is hidden, or the app has none, the page's header starts |
| 706 | with the same switcher. Under the top row, **Search or jump to** opens the |
| 707 | same palette as <kbd>Ctrl</kbd> <kbd>K</kbd>; in Chat and Artifacts, whose |
| 708 | sidebars search their own lists, it stays in the page's header. |
| 709 | |
| 710 | Below it are the lists of the app you are in, each group under a small |
| 711 | heading. Code's lists the workspace's |
| 712 | [projects](#pinned-and-recent-projects), and drills into a project's own |
| 713 | list when you open one, with **‹ All projects** at the top to go back. Its |
| 714 | **Settings** opens one level further: **General**, **Deployments**, |
| 715 | **Domains**, **Agents**, **Guardrails**, **Repository**, **Access**, |
| 716 | **Branches and merging**, **Secrets and variables** and **Webhooks**, each |
| 717 | for the roles that can use it. A link straight to any of these pages opens |
| 718 | the sidebar already there. |
| 719 | |
| 720 | Workspace's sidebar is the [workspace's settings area](#workspace-mode): |
| 721 | its **Overview**, then every settings page in named groups, each one click |
| 722 | away. |
| 723 | |
| 724 | Below 1024px wide, the sidebar opens over the page from the left, from the |
| 725 | header's button, and closes when you open a page. |
| 726 | |
| 727 | ### Workspace mode |
| 728 | |
| 729 | **Workspace**, at the foot of the rail, is everything about the workspace |
| 730 | itself: who has access, what it spends, and how each part of g1t is set up |
| 731 | for it. There is no second Settings inside it: every page is in the |
| 732 | sidebar, under the group it belongs to, and the group you are in stays |
| 733 | open while the others fold when you select their name. A page only owners |
| 734 | open is left out for members; a page that is coming is a greyed **Soon** |
| 735 | row, with a hint saying what it will hold. |
| 736 | |
| 737 | | Group | Page | Who | | |
| 738 | | --- | --- | --- | --- | |
| 739 | | | **Overview** | Members | The workspace at a glance: members, plan and spend. `g1t.sh/<workspace>/-/workspace` | |
| 740 | | **General** | **General** | Owners | The icon, the display name, a one-line description, the address (the slug), [requiring two-factor authentication](#require-two-factor-authentication), [data residency](#data-residency), and deleting the workspace. `-/settings` | |
| 741 | | **Access** | **Members** | Members | Who is in the workspace and their roles, with search and filters; owners [invite people](#add-people), change roles, and see **Outside collaborators**. `-/members` | |
| 742 | | | **Invitations** | Owners | Every invitation to join, filtered by where it stands; send one again, revoke it, copy its link. `-/members/invitations` | |
| 743 | | | [**Permissions**](/guides/permissions/) | Owners | Who may do what, part by part: the base permission, repositories, teams, chat, artifacts, agents, deployments and packages. `-/permissions` | |
| 744 | | | [**Access tokens**](#workspace-access-tokens) | Members | The workspace's own tokens. Owners create and delete them. `-/tokens` | |
| 745 | | | **Personal access tokens** | Owners | The workspace's rules for members' tokens, and approving them. `-/personal-access-tokens` | |
| 746 | | **Money** | [**Spend**](/guides/spend/) | Members | Where the money went, budgets and receipts. `-/spend` | |
| 747 | | | [**Usage**](/guides/usage-and-billing/) | Members | What the agents cost, run by run. `-/usage` | |
| 748 | | | [**AI Gateway**](/guides/ai-gateway/) | Members | Your own code's model requests. `-/gateway` | |
| 749 | | | **Billing and plans** | Members | The plan, the spend limit, prepaying and every charge. `-/billing` | |
| 750 | | **Compute** | [**Runners**](/guides/self-hosted-runners/) | Owners | The workspace's self-hosted machines, their groups and registration tokens. `-/runners` | |
| 751 | | **Code** | **Repositories** | Members | Every repository, and for owners **Recently deleted**, where a [deleted repository](/guides/managing-repositories/#restore-a-repository) can be restored, or purged, for 30 days. `-/repositories` | |
| 752 | | | **Actions** | Members | How workflows run in the workspace: what jobs' tokens may do, and for owners the [workflows the workspace manages](#workflows-the-workspace-manages) in its repositories. `-/actions` | |
| 753 | | | [**Secrets and variables**](/guides/secrets-and-variables/) | Members | What runs and deployments are given. Owners change them. `-/secrets` | |
| 754 | | | [**Webhooks**](/guides/webhooks/) | Members | Where the workspace's events are sent. Owners add and change them. `-/webhooks` | |
| 755 | | | **Deployments**, **Project defaults** | | Soon: defaults for every project's deployments, and what a new project starts with. | |
| 756 | | **Agents** | **Agent settings** | | Soon. Budgets and models are on the [Agents overview](/guides/agents/) today; who may create agents is under Permissions. | |
| 757 | | **Chat** | [**Chat settings**](/guides/chat/#workspace-chat-settings) | Members | Renaming and archiving channels, emoji, default channels. Owners change it. `-/settings/chat` | |
| 758 | | | **Emoji** | Members | The workspace's own emoji. `-/emoji` | |
| 759 | | **Artifacts** | **Spaces and sharing** | | Soon: which spaces a workspace starts with, and how a new artifact is shared by default. | |
| 760 | | **Security** | **Security settings** | Members | The workspace's security policies. `-/security/settings` | |
| 761 | | | [**Guardrails**](/guides/guardrails/) | Members | What agents may reach, run, spend and take. `-/guardrails` | |
| 762 | | | [**Rules**](/guides/rules/) | Members | Rulesets across projects. `-/rules` | |
| 763 | | | [**Audit log**](/guides/audit-log/) | Members | Every change, by whom, to what. `-/audit` | |
| 764 | | **Integrations** | [**Integrations**](/guides/integrations/) | Members | The tools connected for everyone. `-/integrations` | |
| 765 | | | **Applications** | | Soon: OAuth applications the workspace registers. | |
| 766 | |
| 767 | Each page's address is under `g1t.sh/<workspace>/`. The page's header |
| 768 | shows where you are: **General**, **Members / Invitations**, **Permissions**. |
| 769 | Every address that was there before this layout still works. To find |
| 770 | someone, and what they work on, use the |
| 771 | [People directory](/guides/people-and-teams/#the-directory). |
| 772 | |
| 773 | ### Pinned and recent projects |
| 774 | |
| 775 | However many projects a workspace has, Code's sidebar lists a few: |
| 776 | |
| 777 | - **Pinned**: the projects you pinned, in your order, up to eight a |
| 778 | workspace. Pin one with **Pin** on its page, or the pin on its row of the |
| 779 | Projects page or its card on the Overview. Drag a pinned project to move |
| 780 | it, or hold <kbd>Alt</kbd> and press the up or down arrow. |
| 781 | - **Recent**: the projects you opened last that you have not pinned, up to |
| 782 | five. |
| 783 | - **All projects**, with how many there are, opens the Projects page. |
| 784 | |
| 785 | Pins and recent projects are yours: nobody else sees them, and each |
| 786 | workspace has its own. ⌘K finds any project in the workspace, pinned or not. |
| 787 | From the API, use |
| 788 | [`GET /user/pinned_projects/{workspace}`](/reference/api/pinned-projects/list-pinned-projects/) |
| 789 | and the other [pinned projects](/reference/api/pinned-projects/list-pinned-projects/) |
| 790 | operations, or the `workspace` tool's `list_pinned_projects`, |
| 791 | `pin_project`, `unpin_project` and `reorder_pinned_projects` actions |
| 792 | over MCP. |
| 793 | |
| 794 | ### On your phone |
| 795 | |
| 796 | On a screen narrower than a tablet, g1t keeps the same places and moves |
| 797 | them within reach of your thumb: |
| 798 | |
| 799 | | | What it does | |
| 800 | | --- | --- | |
| 801 | | **The bar along the bottom** | **Home**, **Chat**, **Notifications**, **Code** (for members with Code access) and **Agents**, each with what is unread, and **More**. It runs flat along the bottom edge, as the rail stands beside the page on a computer, and the page fills the screen above it. The app you are in is marked as on the rail. It steps aside while the keyboard is up and inside a conversation. | |
| 802 | | **More** | A panel above the bar with **All apps**, [Customize](/guides/customize/), your pinned apps, **Artifacts**, **People**, **Workspace**, and **You and help**: your status, profile and settings, [appearance](#appearance), the documentation, support, status, the keyboard's shortcuts and signing out. | |
| 803 | | **The sidebar button**, at the left of the page's header | Opens the sidebar of the app you are in from the left, most of the screen wide: the same lists and links as on a computer. Tap outside it, or open a page, and it closes. | |
| 804 | | **The tab you are already on** | Tap it again to open that app's sidebar too. | |
| 805 | | **The workspace's name** in the page's header | Switches workspace, or opens your profile or settings. | |
| 806 | |
| 807 | Inside a [project](/guides/projects/), its pages (**Overview**, **Code**, |
| 808 | **Issues**, **Pull requests**, **Agents**, **Workflows**, **Deployments**, |
| 809 | **Insights** and, for the roles that see them, **Security** and |
| 810 | **Settings**) run in a row under its name that scrolls sideways, with the |
| 811 | page you are on kept in view, so issues and pull requests are one tap |
| 812 | away. Pages with more than one view, such as **Files**, **Commits** and |
| 813 | **Branches**, show those as a second row of tabs. |
| 814 | |
| 815 | Menus stay inside the screen, dialogs rise from the bottom and sit on top |
| 816 | of the keyboard while you type, and nothing scrolls the page sideways: a |
| 817 | wide file, diff or table scrolls within its own box. |
| 818 | |
| 819 | ### Signed out, and signing in |
| 820 | |
| 821 | Signing in, signing up, an invite link, the two-factor step, choosing a new |
| 822 | password and making your first workspace each stand on their own: the g1t |
| 823 | logo, the form, and links to the terms, privacy policy, docs, status and |
| 824 | support at the foot. Someone who is not signed in reads public pages, such |
| 825 | as Explore, a profile or a public project, under a plain header with |
| 826 | **Explore**, **Docs**, **Sign in** and **Sign up**; a project's pages run in |
| 827 | the row under its name. |
| 828 | |
| 829 | ## Mission control |
| 830 | |
| 831 | Mission control is Code's **Overview**, at `g1t.sh/<workspace>/-/overview`. |
| 832 | It shows where you are needed in the workspace's code, what its agents are |
| 833 | doing, and what landed without you. Signed in, `g1t.sh` itself opens |
| 834 | [Home](/guides/home/) in the workspace you are in. |
| 835 | |
| 836 | Under the greeting, one line sums up the week, such as *Agents landed 37 |
| 837 | of their 39 changes this week without you, and people landed 8 changes of |
| 838 | their own*. An agent's change landed without you when g1t merged it, by |
| 839 | auto-merge or from the [merge queue](/guides/merge-queue/), with no person |
| 840 | pressing merge. People's changes are their merged pull requests and the |
| 841 | commits they pushed straight to the default branch. A push is a person's |
| 842 | by the account that signed in to make it, not by the name on its commits: |
| 843 | pushes by g1t or a workflow job's token, and commits g1t wrote, are not |
| 844 | counted as people's. **Review N that need you** jumps to the |
| 845 | list, and **New issue** opens a new issue in the project you pick. |
| 846 | |
| 847 | | Across the top | What it counts | |
| 848 | | --- | --- | |
| 849 | | **Projects** | The workspace's projects, and how many were added this month. | |
| 850 | | **Agents** | Agent runs going now, and the hours agents worked in the last 7 days. | |
| 851 | | **Changes this week** | Pull requests merged in the last 7 days, and commits people pushed straight to the default branch, with the change from the 7 days before. The change is left out when g1t cannot read far enough back to count it. | |
| 852 | | **Landed without you** | The share of agents' changes that g1t merged with no person pressing merge. People's own changes are not counted in it. | |
| 853 | | **Need you** | What is waiting on you, and how many of those block work. | |
| 854 | |
| 855 | The list has three tabs. Each row opens to say more; the first is open. |
| 856 | |
| 857 | | Tab | What it lists | |
| 858 | | --- | --- | |
| 859 | | **Needs you** | Pull requests g1t stopped seeing through, reviews asked of you, changes ready for you to merge, failed checks, quiet agents, failed production builds, repository invitations and a usage limit that is close or reached. | |
| 860 | | **Waiting on agents** | Pull requests in an agent's hands (making the change, checking, reviewing, revising, catching up or in the merge queue), and runs going now. | |
| 861 | | **Landed today** | Pull requests merged today in your time zone, and whether a person merged them. | |
| 862 | |
| 863 | Each row in **Needs you** carries the reason it needs you: |
| 864 | |
| 865 | | Reason | Means | |
| 866 | | --- | --- | |
| 867 | | `BLOCKING` | Nothing moves until a person acts: a failed production build, a merge g1t could not make, or the usage limit. | |
| 868 | | `ASKED FOR YOU` | A review or an invitation addressed to you by name. | |
| 869 | | `CHECKS FAILING` | A required check still fails after the agent revised. | |
| 870 | | `OUTSIDE GUARDRAILS` | A run reached a cost or time cap set in [Guardrails](/guides/guardrails/). | |
| 871 | | `NEEDS REVIEW` | The repository wants a person's approval, or the review still asks for changes after the agent revised. | |
| 872 | | `STALLED` | An agent stopped, or has reported nothing for 10 minutes. | |
| 873 | | `READY TO MERGE` | Checks passed and it was approved; the repository lands changes only when a person merges them. | |
| 874 | |
| 875 | Opened, a row shows **The ask** (what g1t stopped with, and who the work |
| 876 | was started for), **What the agent already knows** (its checks, the files |
| 877 | and lines it changes, the test files it touches, how often the agent was |
| 878 | sent back, and what its runs cost) and **Why this needs you**. From |
| 879 | there, **Review and respond** opens it, and where it can be done without |
| 880 | leaving the page you can approve the change, merge it or re-run its failed |
| 881 | jobs. **By impact** puts the most urgent first; **Newest** sorts by time. |
| 882 | |
| 883 | On the right, **This week** charts the changes landed each day, split |
| 884 | by who did the work: agents on their own, agents with a person merging, |
| 885 | and people (their pull requests and direct pushes, merges left out), with what |
| 886 | agents and sandboxes cost over the same days. **Activity** lists what |
| 887 | moved across the workspace, agents marked apart from people. The page |
| 888 | refreshes itself while agents are at work. |
| 889 | |
| 890 | ## Workspace access tokens |
| 891 | |
| 892 | A workspace has access tokens of its own, for CI, integrations and agents |
| 893 | that work for a team. There is no shared service account to create, pay |
| 894 | for or lose the password to. |
| 895 | |
| 896 | | | Personal token | Workspace token | |
| 897 | | --- | --- | --- | |
| 898 | | Belongs to | You | The workspace | |
| 899 | | Acts as | You | The workspace: its name is the author of what it does | |
| 900 | | Can reach | All your workspaces, one of them, or none ([where a token reaches](/guides/authentication/#where-a-token-reaches)) | That workspace only: all of its repositories, or the ones chosen | |
| 901 | | Can do | What its [permissions](/guides/authentication/#permissions) allow, never more than you can | What its permissions allow, with Write on the workspace's repositories (Admin with Repositories: admin); it cannot manage people, tokens or workspaces, and holds no account permissions | |
| 902 | | Expires | 7 days to 1 year, or never where the workspaces it reaches allow | 7 days to 1 year, or never | |
| 903 | | When its creator leaves | Stops working | Keeps working | |
| 904 | | Created by | You, in [Settings → Access tokens](https://g1t.sh/settings/tokens) | An owner, under the workspace's **Settings → Access tokens** | |
| 905 | |
| 906 | They are the same kind of token and are sent the same way; see |
| 907 | [access tokens](/guides/authentication/#access-tokens). With git, any |
| 908 | username works; the token is the password. `GET /user` answers with |
| 909 | `"kind": "workspace"` for one, and `"kind": "user"` for a personal token. |
| 910 | |
| 911 | Every member can see a workspace's tokens: the name, who created each, |
| 912 | its permissions and repositories, when it was last used and when it |
| 913 | expires. Only owners can create, change or delete them. An owner selects |
| 914 | **New token** and fills in the same form as a personal token: a name, an |
| 915 | expiration (No expiration shows a warning), its repositories (all, or the |
| 916 | ones chosen) and its permissions, starting on the CI preset. Each token |
| 917 | shows **Write** or **Admin**: give it **Repositories: admin** to let it |
| 918 | manage webhooks, secrets, deploy keys and who has access, and teams as an |
| 919 | owner would. Select a token to change its permissions or repositories, or |
| 920 | to delete it. |
| 921 | |
| 922 | Which of your members' own personal tokens reach the workspace is set under |
| 923 | **Settings → Personal access tokens**; see |
| 924 | [a workspace's rules for tokens](/guides/authentication/#a-workspaces-rules-for-tokens). |
| 925 | |
| 926 | ## Profiles |
| 927 | |
| 928 | Every person has a profile at `g1t.sh/u/<username>`, apart from the |
| 929 | workspaces at `g1t.sh/<workspace>`. Author names on issues and pull |
| 930 | requests link to it. |
| 931 | |
| 932 | **What it shows.** Your picture, name, username, pronouns, bio, location, |
| 933 | website and when you joined; then your work in three tabs: |
| 934 | |
| 935 | - **Overview:** your contribution calendar, then pull requests merged, |
| 936 | open pull requests and issues opened, and your most recent activity. |
| 937 | - **Pull requests** and **Issues:** everything you opened, and what g1t |
| 938 | opened for you, newest first, |
| 939 | with filters beside the list for state (open, closed, merged), type, |
| 940 | repository and sort order. Add `?tab=pulls&state=merged` and the like to |
| 941 | link to a filtered list. |
| 942 | |
| 943 | **The contribution calendar.** The last year as a square a day, a column a |
| 944 | week, shaded more strongly the more you did that day, with the total |
| 945 | above it ("128 contributions in the last year"). A contribution is a |
| 946 | commit you pushed, an issue or pull request you opened (or g1t opened for |
| 947 | you), and a review you gave. Days are counted in UTC. Hover over a square, |
| 948 | or tap it, to see its day, its count and how many were commits ("5 |
| 949 | contributions on Oct 4, 2026, 3 of them commits"). On a narrow screen the |
| 950 | calendar scrolls sideways inside its card, starting at today. |
| 951 | |
| 952 | Commits count like this: |
| 953 | |
| 954 | - **Pushed to the default branch, or to `gh-pages`.** Commits on other |
| 955 | branches count once they reach the default branch, which is usually a |
| 956 | pull request, and the pull request is counted already. |
| 957 | - **Credited to whoever pushed,** on the day of the push, not to the |
| 958 | commits' authors. Pushes with an agent's, a workspace's or a workflow |
| 959 | job's token are not counted on anyone's calendar. |
| 960 | - **The new commits along the branch's own line,** at most 50 a push. A |
| 961 | merge commit counts once. The first push of a branch counts one, so |
| 962 | importing a long history doesn't fill a single day. |
| 963 | - **Only from the time this was added:** pushes before 9 October 2026 are |
| 964 | not counted. |
| 965 | |
| 966 | **Edit it** in [Settings → Profile](https://g1t.sh/settings/profile). Every |
| 967 | field is optional. The bio takes up to 160 characters and is also what a |
| 968 | link to your profile says. The website must be an `https://` address; |
| 969 | `example.com` is saved as `https://example.com`. Your email address is |
| 970 | never shown. |
| 971 | |
| 972 | **Time zone.** Pick the time zone you are in, by city or region (such as |
| 973 | `America/Denver`), and the [card over your name](#the-card-over-a-name) |
| 974 | shows your local time, so people can tell whether it is a good moment to |
| 975 | ask you something. If your browser's time zone differs from the one |
| 976 | saved, the field offers **Use my browser's time zone**. Choose **Not |
| 977 | shown** to clear it. |
| 978 | |
| 979 | **Who sees what.** A profile is public, but the work and workspaces on it |
| 980 | are filtered for whoever is looking: |
| 981 | |
| 982 | | On the profile | Shown to a visitor when | |
| 983 | | --- | --- | |
| 984 | | An issue or pull request, and its title | They can read its repository: it is public, or they are a member of its workspace | |
| 985 | | The counts, and the contribution calendar | Only what they could see is counted | |
| 986 | | A workspace | They are a member of it too, or you made a public project in it, whose page shows that already | |
| 987 | |
| 988 | Someone signed out sees your public work and the workspaces where you made |
| 989 | a public project; nothing else, and their calendar counts only work in |
| 990 | public repositories. The link preview for a profile uses only public work. |
| 991 | |
| 992 | **How it is laid out.** Signed out, a profile, Explore and Search are |
| 993 | shown with g1t's public header (search, Explore, Docs, signing in) and the page |
| 994 | at full width, with no workspace sidebar. Signed in, the rail stays, but |
| 995 | no mode is lit and no mode's sidebar opens beside these pages: they are |
| 996 | nobody's workspace, and the profile's own left column says whose it is. |
| 997 | |
| 998 | ### The card over a name |
| 999 | |
| 1000 | Hold the pointer over a person's name or picture anywhere on g1t, or move |
| 1001 | the keyboard focus to their name, and a card opens with their profile at a |
| 1002 | glance: |
| 1003 | |
| 1004 | | On the card | Shown when | |
| 1005 | | --- | --- | |
| 1006 | | Picture, name, username and pronouns | Always | |
| 1007 | | Bio and location | They filled them in | |
| 1008 | | Their local time, such as **3:42 PM local time** | They set a [time zone](#profiles) | |
| 1009 | | **Member of** | The same workspaces their profile shows you, at most three named | |
| 1010 | | **Committed to this repository in the past day**, **week** or **month** | You opened it inside a repository you can read, and their latest commit on its default branch is that recent | |
| 1011 | |
| 1012 | On a touch screen no card opens: a tap goes to the profile. `@g1t` has a |
| 1013 | card of its own, about putting g1t to work. `ghost`, which stands in for |
| 1014 | deleted accounts, has no card. |
| 1015 | |
| 1016 | ### Commits and your account |
| 1017 | |
| 1018 | A commit shows as yours, with your username, picture, profile link and |
| 1019 | card, when its author address is one of your |
| 1020 | [confirmed addresses](/guides/authentication/#email-addresses) or your |
| 1021 | noreply address. This holds everywhere a commit appears: the Files page, |
| 1022 | history, a commit, blame, branches, tags, comparisons and the |
| 1023 | Contributors list, which counts every address of yours as one person. |
| 1024 | |
| 1025 | To have commits made on your own machine show as yours without publishing |
| 1026 | your address, commit with your noreply address: |
| 1027 | |
| 1028 | 1. Open [Settings → Emails](https://g1t.sh/settings/emails) and copy your |
| 1029 | noreply address. It looks like |
| 1030 | `<8 characters of your account id>+<username>@users.noreply.g1t.sh`. |
| 1031 | 2. Set it for every repository, or leave out `--global` for one: |
| 1032 | |
| 1033 | ```sh |
| 1034 | git config --global user.email "6c1d0efg+sam@users.noreply.g1t.sh" |
| 1035 | ``` |
| 1036 | |
| 1037 | 3. Commit and push as usual. Commits you made before keep the address they |
| 1038 | were made with; add that address to your account and confirm it to have |
| 1039 | them show as yours. |
| 1040 | |
| 1041 | | A commit's address | Shown as | |
| 1042 | | --- | --- | |
| 1043 | | One of your confirmed addresses, or your noreply address | You | |
| 1044 | | An address added to an account but not confirmed | The name in the commit | |
| 1045 | | An address no account has | The name in the commit, with a plain picture, no link and no card | |
| 1046 | | A deleted account's noreply address, or any of its confirmed addresses during the 30 days it can be restored | `ghost` | |
| 1047 | | g1t's own (`g1t@users.noreply.g1t.sh`) | `g1t` | |
| 1048 | |
| 1049 | `Co-authored-by` trailers are matched the same way, and their pictures sit |
| 1050 | beside the author's. An address itself is never shown on g1t. |