| 1 | --- |
| 2 | title: Workspaces |
| 3 | description: Workspaces, their names and icons, renaming and deleting one, members and roles, 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. After confirming your email |
| 14 | the first thing you do is create a workspace, and repositories go in it. |
| 15 | |
| 16 | 1. Open [g1t.sh/workspaces/new](https://g1t.sh/workspaces/new). |
| 17 | 2. Choose its name in URLs: lowercase letters, digits and single hyphens. |
| 18 | An owner can [change it later](#rename-a-workspace), and old addresses |
| 19 | redirect for 90 days. |
| 20 | 3. Optionally give it a display name. |
| 21 | |
| 22 | From the API, `POST /workspaces` with `slug` and `name`, or the |
| 23 | `workspace` tool's `create` action: |
| 24 | |
| 25 | ```sh |
| 26 | curl -X POST https://api.g1t.sh/workspaces \ |
| 27 | -H "Authorization: Bearer $G1T_TOKEN" \ |
| 28 | -H "Content-Type: application/json" \ |
| 29 | -d '{"slug": "acme", "name": "Acme"}' |
| 30 | ``` |
| 31 | |
| 32 | You can belong to up to ten workspaces. `GET /user`, or the `account` tool's `whoami` action, lists the |
| 33 | ones you belong to. |
| 34 | |
| 35 | A new workspace is free, and **each person can own one free workspace**. |
| 36 | While you own a free workspace, the page shows **You already own a free |
| 37 | workspace** in place of the form, with **Start the plan** on it; the API |
| 38 | answers `402` (`payment_required`). Start the plan on it, or delete it, |
| 39 | then create the new one. Several free workspaces from before are kept, but |
| 40 | each needs the plan (or deleting) before you can create another. See |
| 41 | [one free workspace per person](/guides/usage-and-billing/#one-free-workspace-per-person). |
| 42 | |
| 43 | Usernames and workspaces share one set of names, so a name means the same |
| 44 | thing wherever it appears. Your username is reserved for you: only you can |
| 45 | create a workspace with that name, and nobody can register a username that |
| 46 | is already a workspace. The names `g1t` and `g1t-agent` belong to |
| 47 | [g1t's agent](/guides/working-with-g1t/), and nobody can register them. |
| 48 | |
| 49 | ## Display name, slug and icon |
| 50 | |
| 51 | A workspace has two names: |
| 52 | |
| 53 | | | Example | Where it appears | Changes | |
| 54 | | --- | --- | --- | --- | |
| 55 | | **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 | |
| 56 | | **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) | |
| 57 | |
| 58 | Without a display name, the slug is shown. Where an address is shown, the |
| 59 | slug is in monospace beside the name. Owners change the display name and |
| 60 | description (up to 160 characters) on **Settings → General**, or with |
| 61 | [`PATCH /workspaces/{workspace}`](/reference/api/workspaces/update-workspace/) |
| 62 | (MCP: `workspace` `update`), which takes `name` and `description` and |
| 63 | changes only the fields given. It needs the `workspace:admin` scope, and |
| 64 | is recorded in the [audit log](/guides/audit-log/): |
| 65 | |
| 66 | ```sh |
| 67 | 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."}' |
| 68 | ``` |
| 69 | |
| 70 | Neither changes the slug; that is a [rename](#rename-a-workspace). |
| 71 | |
| 72 | A workspace also has an icon. Without |
| 73 | one, g1t draws its first letter in a colour of its own. To upload one, an |
| 74 | owner opens **Settings → General** and picks an image: |
| 75 | |
| 76 | - PNG, JPEG, WebP or GIF, at most 1 MB. Square images look best. |
| 77 | - An image is checked by its contents, not its name. SVG is refused, |
| 78 | because it can carry script. |
| 79 | - **Remove** goes back to the letter. |
| 80 | |
| 81 | The icon then shows wherever the workspace does, and on its link previews |
| 82 | (PNG and JPEG icons only). Each image is served from |
| 83 | `g1t.sh/avatars/<sha256>`, an address named after its contents, so an icon |
| 84 | that changes gets a new address and nothing shows the old one. |
| 85 | |
| 86 | You can upload a picture of yourself the same way, under |
| 87 | [Settings → Profile](https://g1t.sh/settings/profile). |
| 88 | |
| 89 | ## Rename a workspace |
| 90 | |
| 91 | Renaming changes the slug, the first part of every address under the |
| 92 | workspace. The display name is separate; change it on its own under |
| 93 | **Settings → General → Workspace details**. Only owners can rename a |
| 94 | workspace. |
| 95 | |
| 96 | 1. Open the workspace's **Settings → General** and go to **Address**. |
| 97 | 2. Type the new slug. The field shows the new address, `g1t.sh/<new>`, and |
| 98 | whether the name is available. |
| 99 | 3. Choose **Change address**, read what changes, type the new slug to |
| 100 | confirm, and choose **Change address** again. |
| 101 | |
| 102 | You land on the workspace's settings at its new address. Repositories, |
| 103 | issues and the rest move with it within a few seconds. |
| 104 | |
| 105 | ### What changes |
| 106 | |
| 107 | | | Before | After | |
| 108 | | --- | --- | --- | |
| 109 | | Pages | `g1t.sh/old/<repo>` | `g1t.sh/new/<repo>` | |
| 110 | | Git remotes | `https://g1t.sh/old/<repo>.git` | `https://g1t.sh/new/<repo>.git` | |
| 111 | | API paths | `https://api.g1t.sh/repos/old/<repo>` | `https://api.g1t.sh/repos/new/<repo>` | |
| 112 | | MCP tool arguments | `"owner": "old"` | `"owner": "new"` | |
| 113 | | Production apps | `https://<project>-old.g1t.page` | `https://<project>-new.g1t.page` | |
| 114 | | Previews | `https://<project>-git-<branch>-old.g1t.page` | `https://<project>-git-<branch>-new.g1t.page` | |
| 115 | |
| 116 | These stay the same: the display name, description and icon, members and |
| 117 | roles, access tokens, secrets and variables, integrations, webhooks, |
| 118 | issues and pull requests, and billing, plans and credit. |
| 119 | |
| 120 | ### What redirects, and for how long |
| 121 | |
| 122 | For 90 days after a rename, the old name keeps working: |
| 123 | |
| 124 | | | Behaviour | |
| 125 | | --- | --- | |
| 126 | | Web pages | Answer with a permanent redirect (301) to the same page under the new name, query string included. | |
| 127 | | `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. | |
| 128 | | API and MCP | A call that names the old slug runs under the new one. | |
| 129 | | `g1t.page` apps | Production and preview addresses under the old name redirect to the new ones. | |
| 130 | |
| 131 | Update your remotes now rather than relying on the redirect: |
| 132 | |
| 133 | ```sh |
| 134 | git remote set-url origin https://g1t.sh/<new>/<repo>.git |
| 135 | ``` |
| 136 | |
| 137 | Update anything else that has the old name written into it, too: links in |
| 138 | READMEs and docs, CI configuration, API clients and MCP clients. |
| 139 | |
| 140 | ### Limits |
| 141 | |
| 142 | - A workspace can be renamed once every 24 hours. |
| 143 | - For 90 days the old name is held for the workspace. Nobody else can take |
| 144 | it, and you can rename back to it. |
| 145 | - After 90 days the redirects stop, and anyone can create a workspace or |
| 146 | register a username with the old name. Links and remotes that still use |
| 147 | it then reach whatever has the name, or nothing. |
| 148 | - The new name follows the same rules as a new workspace: lowercase letters, |
| 149 | digits and single hyphens, up to 39 characters, not a reserved word, and |
| 150 | not another workspace's slug or someone else's username. |
| 151 | |
| 152 | ## Data residency |
| 153 | |
| 154 | Data residency says where the git data of the workspace's new repositories |
| 155 | is stored. The section appears in **Settings** once g1t can store |
| 156 | repositories in the EU. Until then it is not shown, and every repository is |
| 157 | stored wherever g1t stores repositories. |
| 158 | |
| 159 | | Setting | What it does | |
| 160 | | --- | --- | |
| 161 | | Anywhere | New repositories are stored wherever g1t stores repositories. The default. | |
| 162 | | 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. | |
| 163 | |
| 164 | To change it: |
| 165 | |
| 166 | 1. Open the workspace, then **Settings**. Only owners see the page. |
| 167 | 2. Under **Data residency**, choose **Anywhere** or **EU only**. |
| 168 | 3. Select **Save**. |
| 169 | |
| 170 | The setting applies to repositories made after you save it, however they |
| 171 | are made: from the site, with the API, by pushing to a new address, or by |
| 172 | importing. Repositories the workspace already has stay where they are. To |
| 173 | move them, contact support; a move keeps each repository's address, history |
| 174 | and settings, and pushes to it wait a few minutes while it happens. |
| 175 | |
| 176 | Data residency covers the git data: commits, branches, tags and files, |
| 177 | including pull requests' working copies, which are stored with their |
| 178 | repository. Issues, pull requests, comments and settings are not affected. |
| 179 | A repository [transferred](/guides/transferring-repositories/) to another |
| 180 | workspace stays where it is stored. |
| 181 | |
| 182 | Changing the setting is recorded in the |
| 183 | [audit log](/guides/audit-log/) as `workspace.residency_changed`. |
| 184 | |
| 185 | ## Delete a workspace |
| 186 | |
| 187 | Deleting a workspace takes everything in it with it, in one step: its |
| 188 | repositories, projects, apps, members' access and tokens. Only an owner can, |
| 189 | signed in as a person, typing the workspace's slug to confirm. |
| 190 | |
| 191 | It is not gone at once. For **30 days** g1t keeps all of it, so that a |
| 192 | deletion you did not mean, or did not make, can be undone: an owner writes |
| 193 | to support@g1t.sh, and support restores the workspace as it was. After 30 |
| 194 | days it is purged for good. |
| 195 | |
| 196 | 1. Open the workspace's **Settings → General** and go to **Danger zone**. |
| 197 | It lists what will go with the workspace: its repositories, projects, |
| 198 | live apps and members. |
| 199 | 2. Choose **Delete workspace**, read what happens, type the workspace's |
| 200 | slug to confirm, and choose **Delete workspace** again. You are taken |
| 201 | back to your own home. |
| 202 | |
| 203 | The one thing that can stand in the way is billing: see |
| 204 | [what billing needs](#what-billing-needs). Repositories you want to keep in |
| 205 | another workspace, [transfer](/guides/transferring-repositories/) first; |
| 206 | their old addresses keep redirecting after the workspace is gone. |
| 207 | |
| 208 | From the API, call |
| 209 | [`DELETE /workspaces/{workspace}`](/reference/api/workspaces/delete-workspace/) |
| 210 | with the slug in `confirm`; over MCP, the `workspace` tool's `delete` |
| 211 | action. |
| 212 | |
| 213 | Some workspaces can never be deleted, by anyone, such as Flagon's, which |
| 214 | runs g1t. Their Danger zone says so instead of offering the button. |
| 215 | |
| 216 | ### What billing needs |
| 217 | |
| 218 | | | | |
| 219 | | --- | --- | |
| 220 | | Money owed | Charged to the workspace's card at once, with no minimum charge. With no card, add one or pay from **Billing** first. | |
| 221 | | An unpaid invoice | Pay it from **Billing** first. | |
| 222 | | Prepaid credit | It would be lost: spend it, or write to support@g1t.sh about a refund, first. | |
| 223 | | 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. | |
| 224 | | The g1t plan | Ends at Stripe at once, not at the end of the period. | |
| 225 | | An enterprise account | A workspace billed through one is moved off it by g1t first: write to support@g1t.sh. | |
| 226 | |
| 227 | A comped workspace owes nothing; only its plan is ended. |
| 228 | |
| 229 | ### What happens |
| 230 | |
| 231 | At once, when an owner deletes it: |
| 232 | |
| 233 | | | | |
| 234 | | --- | --- | |
| 235 | | 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. | |
| 236 | | Access tokens | The workspace's own tokens stop working. Personal tokens are not affected. | |
| 237 | | 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. | |
| 238 | | Projects and apps | Hidden. Its apps are taken offline and nothing builds. Custom domains are kept for a restore. | |
| 239 | | Its pages | Answer 404, and it drops out of search. | |
| 240 | | Billing | What it owes is charged, and its plan ends, as [billing needs](#what-billing-needs). Nothing more is charged. | |
| 241 | | The audit log | Records the deletion. | |
| 242 | |
| 243 | Within 30 days, support can restore it: its members, tokens, repositories, |
| 244 | projects and apps come back as they were, and its apps go back up as its |
| 245 | limit allows. Its plan does not come back by itself: an owner starts it |
| 246 | again from **Billing**. A repository deleted on its own before the |
| 247 | workspace was stays in **Recently deleted**. |
| 248 | |
| 249 | After 30 days it is purged: |
| 250 | |
| 251 | | | | |
| 252 | | --- | --- | |
| 253 | | Repositories | Purged, their git data with them, including any that were in Recently deleted. | |
| 254 | | Projects, apps and custom domains | Removed. | |
| 255 | | Webhooks, integrations, secrets and variables | The workspace's own are removed. | |
| 256 | | Memory and guardrails | The workspace's own are removed. | |
| 257 | | Statements, invoices and the ledger | Kept, for accounting. | |
| 258 | | 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. | |
| 259 | | Old addresses | Redirects for repositories transferred out keep working. The workspace's own pages answer 404. | |
| 260 | |
| 261 | ### The name afterwards |
| 262 | |
| 263 | A deleted workspace's slug is never given to another workspace or used as |
| 264 | someone else's username. While it can still be restored, the slug is held |
| 265 | for it. Links and git remotes that still use it keep |
| 266 | meaning what they meant: a transferred repository's old address keeps |
| 267 | redirecting to it, and nobody can take the name in the meantime. |
| 268 | |
| 269 | The one exception: when the slug is your own username, you may create a |
| 270 | workspace with that name again once the old one is purged. It starts empty, on standard billing terms, |
| 271 | and a repository made in it at an old address ends that address's redirect. |
| 272 | |
| 273 | ## Members and roles |
| 274 | |
| 275 | | Role | Can | |
| 276 | | --- | --- | |
| 277 | | Member | Create repositories, 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: Write unless an owner changes it, which is enough to push, manage issues, merge pull requests, plan work and put g1t to work. | |
| 278 | | Owner | Everything a member can, and manage members, the base permission, 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; see [access and roles](/guides/access-and-roles/). | |
| 279 | |
| 280 | Whoever creates a workspace is its owner. An owner adds people on the |
| 281 | workspace's **People**, `g1t.sh/<workspace>/-/people` (in the sidebar): |
| 282 | |
| 283 | - **By username**: someone already on g1t joins at once, as a member. |
| 284 | - **By email address**: g1t emails an invite that only that address can |
| 285 | use. Without a g1t account, accepting it makes the account and joins the |
| 286 | workspace in one step, and uses one of the workspace's granted invites, or |
| 287 | else one of yours (see [invites](/guides/authentication/#invites)). With |
| 288 | an account, it costs nothing, and they join when they accept. The page |
| 289 | never says which it was. |
| 290 | |
| 291 | The email names you and the workspace and links to the invite's page. |
| 292 | Someone new signs up right there, with the invited address filled in and |
| 293 | already confirmed; someone with an account signs in. Either way they land |
| 294 | in the workspace as a member, with a one-time welcome. See |
| 295 | [using an invite](/guides/authentication/#using-an-invite). |
| 296 | |
| 297 | Pending invites are listed under the members, with a link to copy and |
| 298 | **Revoke**. An owner can also remove a member there. Through the API, use |
| 299 | [`POST /workspaces/{workspace}/invitations`](/reference/api/invites/invite-member/) |
| 300 | (the `workspace` tool's `invite_member` action over MCP). |
| 301 | |
| 302 | To give someone a role on one repository without making them a member, |
| 303 | add them as an [outside collaborator](/guides/access-and-roles/#outside-collaborators). |
| 304 | |
| 305 | **A free workspace cannot add people.** Until it starts the g1t plan, it |
| 306 | cannot add members, send invites, or invite outside collaborators, and an |
| 307 | invite sent before waits until the plan is on. Its members stay. People |
| 308 | shows **Start the plan to invite people** with the button in place of the |
| 309 | form, and the API and MCP answer `402` (`payment_required`). See |
| 310 | [who a free workspace can add](/guides/usage-and-billing/#who-a-free-workspace-can-add). |
| 311 | |
| 312 | ## The workspace's page |
| 313 | |
| 314 | A workspace's own page, `g1t.sh/<workspace>`, has its icon, name, address |
| 315 | and description at the top, then its overview: your |
| 316 | [pinned projects](#pinned-and-recent-projects), then the most active ones, |
| 317 | the pull requests in progress across them, and **All projects**. Members |
| 318 | also see a **Usage** card with this month's spend, and who belongs. |
| 319 | |
| 320 | The workspace's other pages each have a heading of their own and a row in |
| 321 | [the sidebar](#the-sidebar), lit while you are on them. The trail in the |
| 322 | top bar, such as *acme / Projects*, leads back to the workspace's page. |
| 323 | |
| 324 | | Page | Address | Who | | |
| 325 | | --- | --- | --- | --- | |
| 326 | | **Overview** | `g1t.sh/<workspace>` | Everyone | The page above. | |
| 327 | | **Projects** | `/-/projects` | Everyone | Every project you can see. See [the Projects page](#the-projects-page). | |
| 328 | | [**Packages**](/guides/packages/) | `/-/packages` | Everyone | What the workspace publishes. A visitor opens it from **Packages** on the workspace's page. | |
| 329 | | [**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>`. | |
| 330 | | **People** | `/-/people` | Members | Who belongs. Owners add and remove people here. | |
| 331 | | **Insights** | `/-/insights` | Members | Coming soon: how the whole workspace delivers. | |
| 332 | | **Settings** | `/-/settings` | Owners | How the workspace is set up and connected (below). | |
| 333 | |
| 334 | Each person sees the projects they can read: a member whose base permission |
| 335 | is None, an [outside collaborator](/guides/access-and-roles/#outside-collaborators) |
| 336 | or a visitor sees the public ones and those shared with them, without the |
| 337 | workspace's people, deployments or settings. |
| 338 | |
| 339 | Older addresses still work: `/-/members` opens People, and |
| 340 | `g1t.sh/<workspace>?tab=projects` (or `repositories`, `packages`, |
| 341 | `teams`, `people`, `insights` or `settings`) opens that page. |
| 342 | |
| 343 | ### The Projects page |
| 344 | |
| 345 | The Projects page, `g1t.sh/<workspace>/-/projects`, is made for workspaces with hundreds of projects: |
| 346 | |
| 347 | - **Find a project** matches every word you type in a project's name, its |
| 348 | address or its description. Press <kbd>/</kbd> anywhere on the page to |
| 349 | start typing. |
| 350 | - **Filters**: public or private; [what it is](/guides/projects/#what-a-project-is) |
| 351 | (apps, libraries, and tools, docs or other when the workspace has any); the language its |
| 352 | manifests say it is written in; only projects with |
| 353 | [Deployments](/guides/deployments/) on; and archived projects, which are |
| 354 | left out unless you ask for them. Each choice shows how many projects it |
| 355 | holds. |
| 356 | - **Sort** by recently updated (its settings or its last push, whichever is |
| 357 | later), recently pushed, most active, or name. Most active counts each |
| 358 | push, issue or pull request opened or closed, review, comment and |
| 359 | deployment, and what happened a week ago counts half as much. |
| 360 | - **List** or **grid**, 30 projects to a page. |
| 361 | - The arrow keys (or <kbd>j</kbd> and <kbd>k</kbd>) move between projects, |
| 362 | and <kbd>Enter</kbd> opens one. |
| 363 | |
| 364 | Everything you choose is in the address, so a filtered list can be |
| 365 | bookmarked or shared. |
| 366 | |
| 367 | ## The sidebar |
| 368 | |
| 369 | The sidebar is always about one workspace: the one the switcher at its top |
| 370 | names. On a workspace's pages, and on a project in one of your workspaces, |
| 371 | that is the workspace the page belongs to; on a project somewhere you are |
| 372 | not a member, it stays the one you chose last. Choose the workspace's name |
| 373 | to open its page, or the arrows beside it to switch, or for **Workspace |
| 374 | overview** and **All projects**. |
| 375 | [Explore](https://g1t.sh/explore), public projects from all of g1t, is in |
| 376 | the top bar, beside **Docs**. |
| 377 | |
| 378 | It has two parts, a rule apart. Above the rule is what is yours in every |
| 379 | workspace: **Mission control**, your **Inbox** with how many items are |
| 380 | unread, and the repositories **Shared with you** in workspaces you do not |
| 381 | belong to. Below it, under the workspace's name, is the workspace: |
| 382 | |
| 383 | 1. **Overview**, the [workspace's page](#the-workspaces-page). |
| 384 | 2. Its [projects](#pinned-and-recent-projects), ending with **All projects**. |
| 385 | 3. The places work happens across them: **Agent fleet**, **Context**, |
| 386 | **Memory**, **Security** and [**Packages**](/guides/packages/), with |
| 387 | **Insights**, **Boards** and **Roadmap** soon. |
| 388 | 4. **People**, [**Teams**](/guides/teams/), **Usage**, what g1t's runs have |
| 389 | cost (see [usage and billing](/guides/usage-and-billing/)), **Support** |
| 390 | and **Settings**. |
| 391 | |
| 392 | One row is lit wherever you are: **Teams** on a team's pages, **Packages** |
| 393 | on a package's, and **Settings** on every page it opens. An item with an arrow opens a list of its own in the sidebar: |
| 394 | **Settings** slides over to how the workspace is set up and connected, and |
| 395 | the row at the top, **‹ Settings**, slides back: |
| 396 | |
| 397 | | Settings | Who | | |
| 398 | | --- | --- | --- | |
| 399 | | **General** | Owners | The icon, the display name, a one-line description, the address (the slug), [who can create teams](/guides/teams/#who-can-create-teams), and [data residency](#data-residency). | |
| 400 | | **Repositories** | Members | The workspace's repositories. Owners also see **Recently deleted**, where a [deleted repository](/guides/managing-repositories/#restore-a-repository) can be restored, or purged, for 30 days. | |
| 401 | | **Access tokens** | Members | The workspace's own tokens. Owners create and delete them. | |
| 402 | | **Guardrails** | Members | What agents may do and spend across the workspace. Owners change them. | |
| 403 | | [**Secrets and variables**](/guides/secrets-and-variables/) | Members | What runs and deployments are given. Owners change them. | |
| 404 | | **Runners** | Owners | The workspace's self-hosted machines, their groups and registration tokens. | |
| 405 | | [**Integrations**](/guides/integrations/) | Members | Model providers and connected services. Owners connect and remove them. | |
| 406 | | [**Webhooks**](/guides/webhooks/) | Members | Where the workspace's events are sent. Owners add and change them. | |
| 407 | | **Billing and plans** | Members | [The g1t plan](/guides/usage-and-billing/#the-g1t-plan), [limits](/guides/usage-and-billing/#limits) and the statement. Owners start the plan, check a card, prepay and set limits. | |
| 408 | | **Audit log** | Members | [Every action agents, people and tokens took](/guides/audit-log/). | |
| 409 | |
| 410 | **People** is in the main list, for every member to see; owners add and |
| 411 | remove people there, set the |
| 412 | [base permission](/guides/access-and-roles/#the-base-permission), and see |
| 413 | the **Outside collaborators** tab. Each member's row also shows the |
| 414 | [teams](/guides/teams/) they are in that you can see. |
| 415 | |
| 416 | Opening a [project](/guides/projects/) slides the sidebar over to the |
| 417 | project's own list, with **‹ All projects** at the top to go back. Its |
| 418 | **Settings** opens one level further: **General**, **Deployments**, |
| 419 | **Domains**, **Agents**, **Guardrails**, **Repository**, **Access**, |
| 420 | **Branches and merging**, **Secrets and variables** and **Webhooks**, each |
| 421 | for the roles that can use it. A link straight to any of these pages opens |
| 422 | the sidebar already there. |
| 423 | |
| 424 | ### Pinned and recent projects |
| 425 | |
| 426 | However many projects a workspace has, its sidebar lists a few: |
| 427 | |
| 428 | - **Pinned**: the projects you pinned, in your order, up to eight a |
| 429 | workspace. Pin one with **Pin** on its page, or the pin on its row of the |
| 430 | Projects page or its card on the Overview. Drag a pinned project to move |
| 431 | it, or hold <kbd>Alt</kbd> and press the up or down arrow. |
| 432 | - **Recent**: the projects you opened last that you have not pinned, up to |
| 433 | five. |
| 434 | - **All projects**, with how many there are, opens the Projects page. |
| 435 | |
| 436 | Pins and recent projects are yours: nobody else sees them, and each |
| 437 | workspace has its own. ⌘K finds any project in the workspace, pinned or not. |
| 438 | From the API, use |
| 439 | [`GET /user/pinned_projects/{workspace}`](/reference/api/pinned-projects/list-pinned-projects/) |
| 440 | and the other [pinned projects](/reference/api/pinned-projects/list-pinned-projects/) |
| 441 | operations, or the `workspace` tool's `list_pinned_projects`, |
| 442 | `pin_project`, `unpin_project` and `reorder_pinned_projects` actions |
| 443 | over MCP. |
| 444 | |
| 445 | ## Mission control |
| 446 | |
| 447 | Mission control, `g1t.sh` when you are signed in, is your home page. It |
| 448 | shows where you are needed in the workspace you have chosen in the |
| 449 | sidebar, what its agents are doing, and what landed without you. |
| 450 | |
| 451 | Under the greeting, one line sums up the week, such as *Agents landed 37 |
| 452 | of their 39 changes this week without you, and people landed 8 changes of |
| 453 | their own*. An agent's change landed without you when g1t merged it, by |
| 454 | auto-merge or from the [merge queue](/guides/merge-queue/), with no person |
| 455 | pressing merge. People's changes are their merged pull requests and the |
| 456 | commits they pushed straight to the default branch. **Review N that need you** jumps to the |
| 457 | list, and **New issue** opens a new issue in the project you pick. |
| 458 | |
| 459 | | Across the top | What it counts | |
| 460 | | --- | --- | |
| 461 | | **Projects** | The workspace's projects, and how many were added this month. | |
| 462 | | **Agents** | Agent runs going now, and the hours agents worked in the last 7 days. | |
| 463 | | **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. | |
| 464 | | **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. | |
| 465 | | **Need you** | What is waiting on you, and how many of those block work. | |
| 466 | |
| 467 | The list has three tabs. Each row opens to say more; the first is open. |
| 468 | |
| 469 | | Tab | What it lists | |
| 470 | | --- | --- | |
| 471 | | **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. | |
| 472 | | **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. | |
| 473 | | **Landed today** | Pull requests merged today in your time zone, and whether a person merged them. | |
| 474 | |
| 475 | Each row in **Needs you** carries the reason it needs you: |
| 476 | |
| 477 | | Reason | Means | |
| 478 | | --- | --- | |
| 479 | | `BLOCKING` | Nothing moves until a person acts: a failed production build, a merge g1t could not make, or the usage limit. | |
| 480 | | `ASKED FOR YOU` | A review or an invitation addressed to you by name. | |
| 481 | | `CHECKS FAILING` | A required check still fails after the agent revised. | |
| 482 | | `OUTSIDE GUARDRAILS` | A run reached a cost or time cap set in [Guardrails](/guides/guardrails/). | |
| 483 | | `NEEDS REVIEW` | The repository wants a person's approval, or the review still asks for changes after the agent revised. | |
| 484 | | `STALLED` | An agent stopped, or has reported nothing for 10 minutes. | |
| 485 | | `READY TO MERGE` | Checks passed and it was approved; the repository lands changes only when a person merges them. | |
| 486 | |
| 487 | Opened, a row shows **The ask** (what g1t stopped with, and who the work |
| 488 | was started for), **What the agent already knows** (its checks, the files |
| 489 | and lines it changes, the test files it touches, how often the agent was |
| 490 | sent back, and what its runs cost) and **Why this needs you**. From |
| 491 | there, **Review and respond** opens it, and where it can be done without |
| 492 | leaving the page you can approve the change, merge it or re-run its failed |
| 493 | jobs. **By impact** puts the most urgent first; **Newest** sorts by time. |
| 494 | |
| 495 | On the right, **This week** charts the changes landed each day, split |
| 496 | by who did the work: agents on their own, agents with a person merging, |
| 497 | and people (their pull requests and direct pushes, merges left out), with what |
| 498 | agents and sandboxes cost over the same days. **Activity** lists what |
| 499 | moved across the workspace, agents marked apart from people. The page |
| 500 | refreshes itself while agents are at work. |
| 501 | |
| 502 | ## Workspace access tokens |
| 503 | |
| 504 | A workspace has access tokens of its own, for CI, integrations and agents |
| 505 | that work for a team. There is no shared service account to create, pay |
| 506 | for or lose the password to. |
| 507 | |
| 508 | | | Personal token | Workspace token | |
| 509 | | --- | --- | --- | |
| 510 | | Belongs to | You | The workspace | |
| 511 | | Acts as | You | The workspace: its name is the author of what it does | |
| 512 | | Can reach | Every workspace you belong to | That workspace only | |
| 513 | | Can do | What its [scopes](/guides/authentication/#scopes) allow, never more than you can | What its scopes allow, on the workspace's repositories; it cannot manage people, tokens or workspaces | |
| 514 | | Expires | 7, 30 or 90 days (the default), 1 year, or never | The same choices | |
| 515 | | When its creator leaves | Stops working | Keeps working | |
| 516 | | Created by | You, in [Settings → Access tokens](https://g1t.sh/settings/tokens) | An owner, under the workspace's **Settings → Access tokens** | |
| 517 | |
| 518 | They are the same kind of token and are sent the same way; see |
| 519 | [access tokens](/guides/authentication/#access-tokens). With git, any |
| 520 | username works; the token is the password. `GET /user` answers with |
| 521 | `"kind": "workspace"` for one, and `"kind": "user"` for a personal token. |
| 522 | |
| 523 | Every member can see a workspace's tokens: the name, who created each, |
| 524 | when it was last used and when it expires. Only owners can create or |
| 525 | delete them. An owner creates one with a name, an expiry (No expiry shows |
| 526 | a warning) and the same scope checklist as a personal token, starting on |
| 527 | the CI preset. |
| 528 | |
| 529 | ## Profiles |
| 530 | |
| 531 | Every person has a profile at `g1t.sh/u/<username>`, apart from the |
| 532 | workspaces at `g1t.sh/<workspace>`. Author names on issues and pull |
| 533 | requests link to it. |
| 534 | |
| 535 | **What it shows.** Your picture, name, username, pronouns, bio, location, |
| 536 | website and when you joined; then your work in three tabs: |
| 537 | |
| 538 | - **Overview:** pull requests merged, open pull requests and issues |
| 539 | opened, and your most recent activity. |
| 540 | - **Pull requests** and **Issues:** everything you opened, and what g1t |
| 541 | opened for you, newest first, |
| 542 | with filters beside the list for state (open, closed, merged), type, |
| 543 | repository and sort order. Add `?tab=pulls&state=merged` and the like to |
| 544 | link to a filtered list. |
| 545 | |
| 546 | **Edit it** in [Settings → Profile](https://g1t.sh/settings/profile). Every |
| 547 | field is optional. The bio takes up to 160 characters and is also what a |
| 548 | link to your profile says. The website must be an `https://` address; |
| 549 | `example.com` is saved as `https://example.com`. Your email address is |
| 550 | never shown. |
| 551 | |
| 552 | **Who sees what.** A profile is public, but the work and workspaces on it |
| 553 | are filtered for whoever is looking: |
| 554 | |
| 555 | | On the profile | Shown to a visitor when | |
| 556 | | --- | --- | |
| 557 | | An issue or pull request, and its title | They can read its repository: it is public, or they are a member of its workspace | |
| 558 | | The counts | Only what they could see is counted | |
| 559 | | A workspace | They are a member of it too, or you made a public project in it, whose page shows that already | |
| 560 | |
| 561 | Someone signed out sees your public work and the workspaces where you made |
| 562 | a public project; nothing else. The link preview for a profile uses only |
| 563 | public work. |