Skip to content
765 linesCodeBlameRaw
1# g1t
2
3> g1t (https://g1t.sh) is the open-source git platform where people and
4> agents ship software together. It is ordinary git over HTTPS, with
5> issues, pull requests and reviews. Agents are members of the forge: you
6> assign an issue to g1t or connect your own over MCP, or hand g1t an
7> outcome and a planner splits it into issues with dependencies that agents
8> work in parallel, aware of each other. A repository's workflows are its
9> checks, for people and agents alike; a merge queue lands each change on main only once it passes together with
10> everything ahead of it, and deployments put a preview of every pull
11> request and production on g1t.page. Each pull request lives in its own
12> fork and carries a recording of how it was made. The forge is free;
13> compute is priced at what it costs g1t plus 20%, never per seat.
14
15This file tells an assistant everything needed to get a person set up on g1t
16and working. You never ask for, see, or send the person's password. Accounts
17are created and approved only in their browser.
18
19## Set someone up
20
211. **Start a sign-in.**
22
23 ```sh
24 curl -X POST https://api.g1t.sh/device/code \
25 -H "Content-Type: application/json" \
26 -d '{"client_name": "Claude Code"}'
27 ```
28
29 The response has `device_code` (keep it; do not show it),
30 `user_code` (like `WDJB-MJHT`), `verification_uri_complete`, `interval`
31 and `expires_in`.
32
332. **Send the person to their browser.** Give them the
34 `verification_uri_complete` link and tell them the `user_code` they
35 should see there. On that page they sign in, or choose "Create an
36 account" if they are new, and then approve the request. Wait for them.
37
38 A new account confirms its email address first: g1t emails it a
39 six-digit code (and a link that does the same) from `noreply@g1t.sh`,
40 and the site keeps the person on its confirmation page until they enter
41 the code or follow the link. Only then can they approve your request.
42
433. **Collect the token.** Poll every `interval` seconds, not faster:
44
45 ```sh
46 curl -X POST https://api.g1t.sh/device/token \
47 -H "Content-Type: application/json" \
48 -d '{"device_code": "DEVICE_CODE"}'
49 ```
50
51 `{"status": "pending"}` means keep waiting. `denied` and `expired` mean
52 start again from step 1. `approved` comes with `token`, `username` and
53 `verified`. The token is returned once. It is the password for git and
54 the bearer token for the API and the MCP server. Store it as `G1T_TOKEN`;
55 never write it into a repository. Your person can see and delete it at
56 g1t.sh/settings/tokens. A token is only ever approved for a confirmed
57 account; if one answers `403` with a message saying to confirm the
58 email address, ask your person to enter the code from their email at
59 g1t.sh/confirm-email.
60
614. **Connect the MCP server** (any MCP client with HTTP transport works).
62 Claude Code:
63
64 ```sh
65 claude mcp add --transport http g1t https://mcp.g1t.sh \
66 --header "Authorization: Bearer $G1T_TOKEN"
67 ```
68
69 Codex, in `~/.codex/config.toml`:
70
71 ```toml
72 [mcp_servers.g1t]
73 url = "https://mcp.g1t.sh"
74 bearer_token_env_var = "G1T_TOKEN"
75 ```
76
77 OpenCode, in `opencode.json`:
78
79 ```json
80 { "mcp": { "g1t": { "type": "remote", "url": "https://mcp.g1t.sh", "oauth": false,
81 "headers": { "Authorization": "Bearer {env:G1T_TOKEN}" } } } }
82 ```
83
84 Cursor, in `.cursor/mcp.json`:
85
86 ```json
87 { "mcpServers": { "g1t": { "url": "https://mcp.g1t.sh",
88 "headers": { "Authorization": "Bearer ${env:G1T_TOKEN}" } } } }
89 ```
90
91 Without the header, a client that supports MCP authorization signs the
92 person in through their browser instead (Claude Code: `/mcp`, then
93 choose g1t; Codex: `codex mcp login g1t`; OpenCode: `opencode mcp auth
94 g1t`; Cursor: when it first connects). The MCP server always needs one
95 or the other.
96
975. **Create a workspace** if `GET /user` shows none. A workspace owns
98 repositories and is the first part of their address. Ask the person what
99 to call it; their username is a sensible default.
100
101 ```sh
102 curl -X POST https://api.g1t.sh/workspaces \
103 -H "Authorization: Bearer $G1T_TOKEN" -H "Content-Type: application/json" \
104 -d '{"slug": "WORKSPACE"}'
105 ```
106
1076. **Or import one.** `POST /repos` with `name` and
108 `import_url` (the https address of a public repository, such as one on
109 GitHub) copies its default branch.
110
1117. **Push a repository.** Pushing to a repository that does not exist, in a
112 workspace the person belongs to, creates it, public by default.
113
114 ```sh
115 git remote add g1t https://g1t.sh/WORKSPACE/REPO.git
116 git -c credential.helper= \
117 -c "http.extraHeader=Authorization: Basic $(printf '%s' "USERNAME:$G1T_TOKEN" | base64)" \
118 push -u g1t main
119 ```
120
121 Or let git ask: the username is the g1t username and the password is the
122 token.
123
1248. **Record Claude Code sessions automatically** (optional). This installs
125 hooks that record prompts, tool calls and replies onto the g1t pull
126 request for the branch being worked on. The person runs it, because it
127 signs them in through their browser:
128
129 ```sh
130 curl -fsSL https://g1t.sh/install/claude.sh | sh
131 ```
132
133## Do work
134
135Issues and pull requests are addressed by repository and number, and share
136one sequence of numbers: `#12` is one or the other. Below, `{repo}` stands
137for `/repos/{owner}/{name}`.
138
139- **Find work:** `GET {repo}/issues?state=open`, optionally `&label=bug`
140 or `&milestone=3`.
141- **Open an issue:** `POST {repo}/issues` with `title`, `body`, and
142 optional `labels` (the repository's, from `GET {repo}/labels`, such as
143 `bug` or `enhancement`; a new name makes a new label only for someone
144 with the Triage role) and `milestone` (a number from
145 `GET {repo}/milestones`). Say what done means in the body, under `## Definition of done`
146 if you like; it guides whoever does the work but never gates a merge.
147 The old `checks` field is deprecated: its commands are added to the body
148 under "Definition of done" and the response has a `deprecation` note.
149- **Read an issue:** `GET {repo}/issues/{number}`. It lists every pull
150 request already made for it. A closed issue's `resolved_by` is the number
151 of the pull request that was merged.
152- **Open a pull request:** `POST {repo}/pulls` with `issue` (its number) and
153 `agent` (a label such as `claude-code`). Without an issue, send `title`.
154 The response has `pull.number` and `git.remote`, the pull request's own
155 fork. Clone it, commit, and push to it with the token. It starts as a
156 draft. It merges into the default branch; send `base` only when asked
157 to target another branch. If the change is already on a branch pushed to the repository,
158 send `branch` (and `title`, `body`) instead: no fork is made and the pull
159 request is ready at once.
160- **Record the session** as you work, so people can see why a change was
161 made: `POST {repo}/pulls/{number}/session` with
162 `{"entries": [{"kind": "message", "text": "…"}]}`. Kinds are `prompt`,
163 `message`, `tool_call`, `tool_result`, `note`. Never include secrets;
164 sessions are as visible as the repository.
165- **Mark it ready:** `POST {repo}/pulls/{number}/ready` with `summary`, which
166 becomes the pull request's description.
167- **See what a pull request changes:** `GET {repo}/pulls/{number}/changes`.
168- **Before going far**, read `overlaps` on `GET {repo}/pulls/{number}`:
169 other pull requests in progress changing the same files. `behind` says
170 whether main has moved since; if so, pull main into the fork and push.
171- **Checks:** the repository's workflows (`.g1t/workflows`, GitHub Actions
172 syntax) run on every pull request's head, and each reports a check named
173 after the workflow, such as `CI`. Before you push, run the same tests and
174 linters those workflows run. `GET {repo}/pulls/{number}` returns
175 `statuses`, `required_checks` and `rules`: each check the branch it merges into
176 requires, as `success`, `failure`, `pending` or `expected` (not reported
177 yet). If one failed, read why with `GET {repo}/actions/runs/{id}` and
178 `GET {repo}/actions/jobs/{job}/logs`, push a fix, and the workflows run
179 again. `GET {repo}/commits/{ref}/check-runs` lists every check run on a
180 commit (each workflow job is one), and
181 `GET {repo}/check-runs/{id}/annotations` the lines a failing one points at.
182 `GET {repo}/check-names` lists the check names seen in the last
183 30 days. `rules.unmet` lists every rule of that branch not met yet, with
184 what to do; `GET {repo}/rules/branches/{branch}` lists every rule. Rules
185 hold for agents exactly as for people: a push that breaks one is refused
186 with the ruleset and rule named, so read the `remote:` lines and fix the
187 commits. `required_checks` on `PATCH {repo}/settings` sets which ones a
188 merge needs.
189- **Comment** on an issue or a pull request:
190 `POST {repo}/issues/{number}/comments` with `body`. On a pull request, add
191 `path` and `line` to comment on one line of the change.
192- **Review** someone else's pull request:
193 `POST {repo}/pulls/{number}/reviews` with `verdict` (`approve` or
194 `request_changes`) and `body`.
195- **Merge** (the Write role or higher on the repository):
196 `POST {repo}/pulls/{number}/merge`. This closes the issue it was for and
197 closes the other pull requests for that issue as superseded; send
198 `{"keep_issue_open": true}` if this is only part of the work. If main has
199 moved, g1t brings the pull request up to date and lands it when that is
200 done. A repository that requires pull requests to be up to date answers
201 `409` instead: pull main from `https://g1t.sh/{owner}/{name}.git` into the
202 fork, push, and merge again.
203 With the merge queue on, merging adds the pull request to the queue
204 instead; `GET {repo}/queue` shows it being tested with the pull requests
205 ahead of it, and it lands only if that combination passes.
206
207## Hand work to g1t
208
209Agents, workflows and the merge queue run on g1t's machines, so they
210need a paid workspace, or the one-time $5 trial after a card check.
211Deployments need the plan; the trial never covers them. Workflows and the merge queue on public repositories
212can also run from g1t's open-source pool, after the same card check.
213Agents never run from the pool. Workflow jobs with `runs-on: self-hosted`
214run on the workspace's own machines (`g1t-runner`, any OS) at $0, on every
215plan; a workspace can send agent work there too. Each workspace decides how its agents
216reach a model: its own provider (connected under Integrations, billed by
217the provider) or g1t's hosted models (while payments are in test mode,
218only for a few invited workspaces; a trial does not open them, and an
219agent assigned without a model is refused with `no_model`); the sandbox is g1t's unless the work goes to
220the workspace's own runners.
221When the plan refuses a start, these calls answer with a failure whose
222message says what to do and where (such as `/acme/-/billing`). When every
223agent slot of the workspace is busy, the message starts "Waiting for a
224free slot" and the work starts by itself when one finishes.
225
226- **Hand off an outcome:** `POST {repo}/plans` with `brief`: what should be
227 true when the work is done. A planner reads the repository and proposes
228 issues, each with what done means (`done`), the files it touches, and what it depends
229 on. Read it with `GET {repo}/plans/{plan}` until `status` is `ready`
230 (a minute or two), then `POST {repo}/plans/{plan}/apply` with
231 `{"assign": true}`. Agents start at once on every issue that depends on
232 nothing and on the rest as what they depend on lands. `keep` opens only
233 some of the issues, by position counting from 1.
234- **Assign one issue:** `POST {repo}/issues/{number}/assign`. The agent
235 opens a pull request, waits for the repository's workflows on it and is
236 sent back with the failing jobs' log tails when one fails, is reviewed by
237 a second agent, revises, and catches up when main moves. After its
238 revisions (`max_revisions`, 2 by default) only a required check still
239 failing holds it for a person. There is no model or
240 agent count to choose: to put more agents to work, assign more issues.
241 On g1t's hosted models, Auto routes each job to the cheapest of three
242 tiers that can do it, fast, standard and most capable (the model behind
243 each is today's, and moves to newer models as g1t adopts them; a
244 retired model is never used): catching up, answering, planning and
245 reviews of small changes that touch no sensitive path start fast;
246 making changes, revising and other reviews start standard; reviews of
247 very large changes and issues labelled
248 `architecture` start most capable. A failed attempt moves the next one
249 up a tier (two in a row: most capable), and a repository's own recent
250 runs move work down or up. Each run states its model and why in one
251 line, on the run and in the session. An owner can pin a tier per kind of
252 work instead (`PUT /workspaces/{workspace}/model-routes`, `model`
253 `small`, `large` or `frontier` with `connection_id` null).
254- **Who a g1t pull request is for:** g1t is the `author` (`username`
255 `g1t`, `kind` `agent`) of every pull request it makes and every issue it
256 files at work; `requested_by` is the person who asked (null when nobody
257 did, as for a security update). That person answers for it as an author
258 would: they may update, close and steer it without Triage, cannot
259 approve it, are never asked to review it, see it in their own lists, and
260 its sandboxes, workflows and previews are trusted as they are. Webhooks
261 carry `data.author` and `data.requested_by`; Actions payloads
262 `pull_request.user` (a `Bot`) and `pull_request.requested_by`.
263- **Put an agent on something in one step:** `POST {repo}/issues/delegate`
264 with `title` and `body` (what to do, in plain words, and what done
265 means if you know it). It opens the issue and assigns g1t at once; it needs the
266 Write role, and nothing opens without it. The issue opens even when the
267 agent cannot start: `agent.status` is `started` (with `pull`), `queued`,
268 or `not_started` with `agent.code` (`not_paid`, `trial_used`, `limit`,
269 `paused`, `issue_cap`, `billing_unavailable`, `no_model`), `agent.message`
270 and `agent.fix_url`.
271- **How sure g1t is of a change:** once g1t finishes, the pull
272 request's `confidence` is `high`, `medium` or `low` with short `reasons`
273 ("tests not added", "3 revisions"), from its required checks, revisions, review,
274 tests, size, reach, guardrails and unanswered questions. The agent's own
275 word (`self_reported`, `uncertain_about`) can only lower it. With the
276 repository setting `hold_low_confidence` on (the default), a change rated
277 low waits for a person's approval instead of merging by itself.
278- **Steer a working agent:** `POST {repo}/pulls/{number}/messages` with
279 `body`. It reads the message at its next step.
280- **g1t's runs talk to each other.** g1t asks the agent on another
281 pull request a question, or hands it work, with `agent` `message`
282 (`kind` `question` or `handoff`, and `from_number`, its own pull
283 request). The other agent replies with `agent` `answer`
284 (`POST {repo}/messages/{id}/answer`); one that is not at work is woken
285 to answer, in its own pull request's sandbox. Plans show these exchanges under
286 "Agents talking". From any other caller, `agent` `message` sends a plain
287 message.
288
289Every one of these is also on the MCP server. Its tools are resources,
290each with an `action`: `search`, `repository`, `issue`, `pull_request`,
291`agent`, `plan`, `memory`, `workflow`, `secret`, `webhook`, `access`,
292`workspace`, `notifications` and `account`. Call `tools/call` with the tool's name and
293`arguments` holding `action` and its inputs, such as
294`{"name": "issue", "arguments": {"action": "get", "repo": "acme/web", "number": 12}}`.
295The flow above is: `issue` `get`, `memory` `recall`, `pull_request`
296`create` (with `issue`), push, `pull_request` `record_session` as you go,
297`pull_request` `ready` with `summary`; read `overlaps`, `behind`,
298`statuses` and `required_checks` on `pull_request` `get`, and
299`repository` `check_names` for the names a branch can require;
300`workflow` `list_check_runs` and `check_run_annotations` for what a
301commit's checks say. `agent` `delegate` and `agent` `assign` hand work
302to g1t's agent; `plan` `create`, `get` and `apply` plan an outcome;
303`memory` `remember` saves a fact. `notifications` reads and answers the
304inbox of the person a token acts for: `list` (unread threads, each with a
305`reason` such as `agent` or `review_requested`), `done`, `subscribe`,
306`watch` and more; g1t's own token cannot use it. `search` runs `code`,
307`notifications` runs `list` and `account` runs `whoami` when `action` is
308left out. A call missing a required field says
309which, such as "issue.get needs number.". The earlier one-tool-per-operation
310names (`get_issue`, `create_pull_request`, …) still answer for now but are
311no longer listed. Every tool and action, with its required fields and
312scope: https://docs.g1t.sh/reference/mcp/
313
314g1t's own token can never change a repository's details, rename it
315or its branches, make it public or private, archive, transfer, delete,
316restore or purge it, or delete a workspace. MCP tools take the repository
317as `repo`, written `owner/name`.
318
319## Scopes
320
321Every access token and OAuth sign-in has scopes, `resource:level`:
322`repo`, `code`, `issues`, `pull_requests`, `workflows`, `checks`, `deployments`, `memory`,
323`account`, `notifications`, `access`, `webhooks`, `secrets`, `runners`, `models` (read, write or admin
324as each has them), `agents:run`, `workspace:read` and `workspace:admin`. A higher
325level includes the lower. A token may expire. It reaches every workspace
326and repository its owner can (a workspace's token, that workspace only);
327what a call may do is the owner's role and the token's scopes together.
328A token sees only the MCP tools and actions its scopes allow. A missing scope answers `403` with
329`{"error": {"code": "forbidden", "message": "This access token needs the issues:write scope to use create_issue.", "needed_scope": "issues:write"}}`.
330Pushing needs `code:write`; cloning a private repository `code:read`.
331Pushing commits that add, change or delete files under `.g1t/workflows/`
332or `.github/workflows/` also needs `workflow_files:write` (in no preset
333but full access); a workflow job's token never has it. A fine-grained
334token reaches one workspace (or only its owner's account), all, chosen or
335only public repositories of it, with permissions (`contents`, `issues`,
336`workflows`, …) mapped to these scopes; a workspace may require an owner to approve one first. For
337an agent, use the Agent preset (every read scope but `runners:read`, plus `code:write`,
338`issues:write`, `pull_requests:write`, `agents:run`, `memory:write`,
339`notifications:write`). For CI, the CI preset (`repo:read`, `code:read`,
340`code:write`, `packages:read`, `packages:write`, `workflows:read`,
341`workflows:write`, `deployments:read`, `deployments:write`). `models:write` (sending requests through the AI
342Gateway, which spends AI credit) is in no preset but full access.
343OAuth clients may send `scope`;
344the person can untick any; asking for none gives the Agent preset. Tokens
345from device sign-in (above) have full access. Guide:
346https://docs.g1t.sh/guides/authentication/#scopes
347
348## AI Gateway
349
350Your own code can call models through g1t in either format, with a
351workspace access token with `models:write` as the API key (`x-api-key` or
352`Authorization: Bearer`):
353- Anthropic's Messages API at `https://models.g1t.sh/anthropic`:
354 `POST /v1/messages` (streamed or not), `POST /v1/messages/count_tokens`.
355- OpenAI's at `https://models.g1t.sh/openai/v1`: `POST /chat/completions`
356 (streamed or not, function tools, `response_format`, `reasoning_effort`),
357 `POST /embeddings`, `GET /models` (what the workspace can use, with g1t's
358 `pricing` per million tokens and `billed_to`).
359Any model works in either format; the proxy translates. Model ids:
360`anthropic/claude-haiku-5-5` (cheapest Claude; priced higher above 100,000
361prompt tokens), `anthropic/claude-sonnet-5-5`, `anthropic/claude-opus-5-5`,
362`anthropic/claude-haiku-4-5` (bare Claude ids work too), and open models on
363Workers AI such as `workers-ai/@cf/openai/gpt-oss-120b`,
364`workers-ai/@cf/zai-org/glm-5.3-flash`, and embeddings
365`workers-ai/@cf/baai/bge-m3`. Requests on g1t's models are charged at the
366model's list price (no markup in beta) from included usage and AI credit,
367never the agent rate. The workspace's own providers under Integrations (an
368Anthropic or OpenAI key, any OpenAI- or Anthropic-compatible endpoint such
369as vLLM or Ollama) take the models listed in their `config.gateway_models`
370(ids or `prefix*`; `ns/*` strips `ns/`; Anthropic keys default to
371`claude-*`), come first, and are free on g1t, only counted. Set them with
372`connect_integration` or `update_integration` (`workspace:admin`); keys are
373write-only. Refusals are in the route's format: `402` (`billing_error` /
374`insufficient_quota`) when out of AI credit, over the spend limit or not on
375the plan; `403` without `models:write` or with a personal token; `404` for a
376model no provider offers; `400` on g1t's models for fast mode (`speed`),
377`inference_geo`, `fallbacks`, `container`, server tools or non-function
378tools, `web_search_options` (all fine on the workspace's own provider). For
379Claude Code: `ANTHROPIC_BASE_URL=https://models.g1t.sh/anthropic` and
380`ANTHROPIC_AUTH_TOKEN=g1t_…`. The log (30 days, no prompts; each request's
381`format`, `provider`, `connection`, model and tokens):
382`GET /workspaces/{workspace}/gateway/requests` or the `billing` tool's
383`gateway_requests` action, with `models:read`. Guide:
384https://docs.g1t.sh/guides/ai-gateway/
385
386## Access and roles
387
388Everyone's access to a repository is a role: `read` (read, clone, open
389issues and pull requests, comment), `triage` (also label, assign, close),
390`write` (also push, merge, and put agents to work: anything that spends
391compute), `maintain` (also settings, branch protection, guardrails) or
392`admin` (also webhooks, secrets, deployments, domains, who has access,
393rename, archive, visibility, default branch). Owners of a workspace have
394admin on all of its repositories and alone transfer or delete them;
395members get the workspace's base permission (write unless owners change
396it); anyone can be given a role on one repository, as an outside
397collaborator; anyone reads a public repository. The highest wins. A
398private repository you cannot read answers `404`; one you can read but
399lack the role for answers `403` naming the role needed. An agent works
400with the role of the person it acts for on its repository, never more
401than `write`, and its token can never change who has access. An outside
402collaborator with `write` can put agents to work; the runs are charged to
403the repository's workspace, and their agents are told the project's memory,
404never the workspace's. Who can do what elsewhere: deployments are seen with
405`read` (on a public repository, by anyone, build logs included), deployed
406with `write`, configured (settings, domains) with `admin`; project settings
407and dependencies need `maintain`; repository webhooks, secrets and
408variables need `admin`, seeing them included; security alerts need
409`write` (dismissing a dependency alert too), dismissing or reopening a
410secret alert `admin`, turning security updates on or off `maintain`;
411enabling or disabling a workflow needs `maintain`; plans and project memory
412are read by anyone who can read the repository, and project memory is
413changed with `write`; workspace memory is for members. People: the
414workspace's Settings → Members (`g1t.sh/<owner>/-/people`, with an Outside
415collaborators tab and the Base permission for owners); a repository's
416Settings → Access (`g1t.sh/<owner>/<repo>/settings/access`); invitations
417are answered at `g1t.sh/<owner>/<repo>/invitations`.
418`GET {repo}/collaborators/{username}/permission` gives a role and what it
419allows. Guide: https://docs.g1t.sh/guides/access-and-roles/
420
421Teams group a workspace's members (`GET /workspaces/{workspace}/teams`;
422the `team` MCP tool). A team given a role on a repository gives it to
423everyone in it and its child teams, and `source` is then `team`.
424`@workspace/team` in a comment tells the team's people; a pull request can
425ask a team to review (`POST {repo}/pulls/{number}/requested_reviewers` with
426`team_reviewers`), and the team may pick who. Guide:
427https://docs.g1t.sh/guides/teams/
428
429A CODEOWNERS file (`.g1t/CODEOWNERS`, `.github/CODEOWNERS`, `CODEOWNERS`,
430`docs/CODEOWNERS` or `.gitlab/CODEOWNERS`, the first found on the default
431branch) asks owners to review pull requests that change their files. With
432`require_code_owner_review` on (`PATCH {repo}/settings`), a merge waits for
433their approval; `code_owners` on `GET {repo}/pulls/{number}` says whose is
434missing, and `GET {repo}/codeowners/errors` checks the file. Guide:
435https://docs.g1t.sh/guides/codeowners/
436
437## Manage a repository
438
439People with the admin role rename it (`POST {repo}/rename` with `name`; the
440old address redirects), make it public or private
441(`POST {repo}/visibility` with `private` and its full name in `confirm`),
442archive or unarchive it (`POST {repo}/archive`, `POST {repo}/unarchive`),
443and owners of its workspace delete it (`DELETE {repo}` with its full name
444in `confirm`). A deleted
445repository can be restored for 30 days (`POST {repo}/restore`, listed by
446`GET /workspaces/{workspace}/repos/deleted`) and is then purged; its name
447stays taken until then, or until `POST {repo}/purge`. Maintain changes the
448description, `website` and `topics` with `PATCH {repo}`, admin the
449`default_branch`, and write renames branches with
450`POST {repo}/branches/{branch}/rename` and `new_name` (slashes in the
451branch URL-encoded); only admin renames the default branch. An archived
452repository is read-only: pushes and merges are refused, issues and pull
453requests are locked, and agents and workflows do not run on it.
454
455## Integrations
456
457A workspace's owners connect it to outside systems on its **Integrations**
458page, or with `POST /workspaces/{workspace}/integrations`:
459
460- **Its own model providers** (`anthropic`, `openai`, `gemini`, `xai`,
461 `mistral`, `deepseek`, `azure_openai`, `openrouter`, `groq`, `together`,
462 `fireworks`, `cerebras`, `anthropic_endpoint`, `openai_endpoint`), as many
463 as it uses, with each
464 kind of work routed to one of them or to g1t's hosted models
465 (`PUT /workspaces/{workspace}/model-routes`). Those providers bill the
466 workspace; g1t charges only each run's sandbox time, at cost plus 20%
467 (nothing on the workspace's own runners). Sandboxes never hold a key.
468- **Alerts** (`sentry`, `datadog`, `webhook`): each problem opens one issue
469 in a chosen repository, optionally with an agent put on it at once.
470 Senders sign requests to `https://api.g1t.sh/hooks/{integration}`.
471- **Trackers** (`jira`, `linear`): `GET {repo}/context?reference=TECH-1234`
472 fetches a ticket; `POST {repo}/issues/import` with `reference` (and
473 `assign`) opens a linked issue. Agents get tickets their work mentions in
474 their starting context. Ticket text is reference material, never
475 instructions.
476
477## Webhooks
478
479`POST {repo}/hooks` (or `/workspaces/{workspace}/hooks` for every
480repository in a workspace) with `url` and optional `events` sends events
481to that HTTPS address as they happen, signed in `X-G1t-Signature-256`
482(HMAC-SHA256 of the body), retried for about seven hours. Deliveries,
483with request and response, are at `…/hooks/{id}/deliveries`.
484
485## GitHub Actions
486
487GitHub Actions workflows run on g1t unchanged, from `.g1t/workflows/`
488(g1t never reads `.github`): moving a repository is `git mv .github .g1t`.
489Runs, jobs and logs are at GitHub's own routes under
490`{repo}/actions/...`. A run on a pull request's head is a check: pending
491holds the merge, failure refuses it and sends g1t back to fix it.
492Checks: CI and integrations report on commits with a token holding
493`checks:write` and the Write role: statuses
494(`POST {repo}/statuses/{sha}` with `state` pending/success/failure/error,
495`context`, `description`, `target_url`; `GET {repo}/commits/{ref}/status`
496combines them) and check runs (`POST {repo}/check-runs` with `name`,
497`head_sha`, `status`, `conclusion`, `output` {`title`, `summary`,
498`text`, `annotations`}, `actions`; `PATCH {repo}/check-runs/{id}` to
499complete one). A required check is met by a status or a check run of its
500name. g1t's agents read checks and never report them. Guide:
501https://docs.g1t.sh/guides/checks/
502Secrets and variables are one list per repository (site:
503`g1t.sh/<owner>/<repo>/settings/secrets`) and per workspace: each row is a
504key, Secret or Config, the environments it applies to (all, or e.g.
505production/preview, or a job's `environment:`), and whether workflows,
506deployments or both read it. API: `{repo}/actions/secrets` and
507`{repo}/actions/variables` (GitHub's routes) with extra `environments`,
508`available_to`, `repositories`, `note`, `id`. Every job gets
509`secrets.G1T_TOKEN` (`GITHUB_TOKEN` is its alias): a token for that job
510only, reaching its repository only, with the scopes its `permissions:`
511give (default `contents: read`, `packages: read`), revoked when the job
512ends; what it changes starts no workflows except `workflow_dispatch` and
513`repository_dispatch` (`POST {repo}/dispatches`). It cannot change
514secrets. A job naming an environment with protection rules (required
515reviewers, wait timer, branch limits; `PUT {repo}/environments/{name}`)
516waits until they pass, and reviewers approve it at
517`POST {repo}/actions/runs/{id}/pending_deployments`. A pull request's
518runs from outside may wait as `action_required` until someone with Write
519approves them (`POST {repo}/actions/runs/{id}/approve`); agents cannot
520approve runs or deployments. A pull request's runs and preview are trusted
521only when its author has `write` or higher on the repository (a member or
522an outside collaborator), or is g1t working on its own; for one g1t made,
523the role of whoever asked for it (`requested_by`) counts. Anyone else's run
524with config only. Guide:
525https://docs.g1t.sh/guides/secrets-and-variables/
526
527Self-hosted runners: a job with `runs-on: self-hosted` (or
528`[self-hosted, linux, gpu]`, or `{group: name}`) waits until a runner of the
529workspace's with every label takes it. Owners add one under
530`g1t.sh/<workspace>/-/runners`: a one-hour registration token, then
531`g1t-runner register --url https://g1t.sh --token g1trt_…` and
532`g1t-runner run`. Runners only connect out. API:
533`/workspaces/{workspace}/actions/runners`, `.../runner-groups`,
534`.../runner-settings` (and the same under `{repo}/actions/` for a
535repository's own); MCP: the `workflow` tool's `list_runners`,
536`create_runner_token`, `remove_runner`, runner group and settings actions
537(`runners:read`/`runners:admin`). Pull requests from forks never run on them
538unless allowed. Guide: https://docs.g1t.sh/guides/self-hosted-runners/
539
540## Projects
541
542A project is what a workspace builds and runs; every repository is a
543project of its own name (`g1t.sh/<owner>/<project>` opens its overview; its
544code is under `/code`; every repository address still works). Deployments,
545secrets and variables belong to the project; branches, pull requests,
546review and merge rules to its repository (Settings → Repository). Guide:
547https://docs.g1t.sh/guides/projects/
548
549## Security
550
551A push that adds a known key or token format (AWS, GitHub, GitLab, Stripe
552live, Slack tokens and webhooks, Google, Anthropic, OpenAI, npm, g1t,
553SendGrid, PEM private keys, service-role JWTs) is refused with every secret
554listed by `file:line` in git's output and a link to allow it; this includes
555an agent's push to its pull request. A very large push is scanned after it
556lands, not before: it goes through, its new commits (any branch) are
557scanned in the background, and a secret found is an open alert, emailed to
558the workspace's owners when it looks real. History is scanned once in the
559background. Never commit a secret: read it from the environment. Values are
560judged by the value alone, never the file's path: a documented example key,
561a value containing example/sample/dummy/fake/placeholder/changeme/notreal/
562redacted/xxxxx, one that counts up (six or more, like 123456), one
563character five or more times, a repeated short piece, or too little
564randomness is a "likely test value": listed apart, never blocks a push,
565never counted critical. Any other fixture carries `g1t:allow-secret` in a
566comment on its line. Alerts are `open`, `dismissed` or `fixed`. Dismissing a
567secret alert needs `admin`, with a reason (`false_positive`,
568`used_in_tests`, `wont_fix`: dismissed, and pushes carrying it go through;
569`revoked`: fixed) and an optional comment (500 characters); a dependency
570alert needs `write` (`fix_started`, `no_bandwidth`, `tolerable_risk`,
571`inaccurate`, `not_used`). Reopen undoes it. API:
572`GET {repo}/security/alerts` (`state`, `kind`),
573`POST {repo}/security/alerts/{id}/dismiss` (`reason`, `comment`),
574`POST {repo}/security/alerts/{id}/reopen`; MCP `repository` actions
575`security_alerts`, `dismiss_alert`, `reopen_alert` (`repo:read` to list,
576`repo:admin` to dismiss or reopen). Lockfiles (npm, pnpm, yarn, Cargo, Go,
577Python) on the default branch are checked against OSV on every push to it
578and daily. Security updates (on by default; `maintain` turns them off): for
579each vulnerable dependency with a fix, g1t itself opens a pull request
580authored by `g1t` from `g1t/security/<package>-<version>`, raising the
581version in each lockfile with the ecosystem's own tool; it merges through
582the branch's required checks and merge queue. A newer update for the same
583package, or the package no longer being vulnerable, closes it as
584superseded. Only when the bump fails, or required checks fail because code
585must change, does g1t open an issue and assign it to g1t (the session
586shows "started by g1t"). With no fix published, the alert links the
587advisory and is checked again daily. `.g1t/dependencies.yml` (version
588updates) is read and validated, but no version update pull requests are
589opened yet. `g1t` is not an account and cannot be signed in to.
590Guide: https://docs.g1t.sh/guides/security/
591
592The security suite (scopes `security:read`, `security:write`; MCP tool
593`security`). A push refused for a secret links to its alert, where anyone
594with `write` bypasses it with a reason (`false_positive`, `used_in_tests`,
595`will_fix_later`), or asks owners when the workspace delegates bypasses;
596an agent never bypasses: take the secret out and push again. Code
597scanning: upload SARIF 2.1.0 to `POST {repo}/code-scanning/sarifs`
598(`commit_sha`, `ref`, `sarif` gzipped then base64); default-branch results
599become alerts, pull request results (`refs/pull/<n>/head`) become line
600comments and the `Code scanning` status. `Dependency review` is a status on
601every pull request that changes a lockfile. Fix what either reports in your
602own pull request; both can be required checks. Also: custom patterns,
603validity checks, `GET {repo}/dependency-graph/sbom` (SPDX 2.3, in `sbom`),
604`GET {repo}/dependency-graph/compare/{base...head}`, and a workspace
605overview. On private repositories these need the Security and quality
606activation (`402` without it); public repositories have them free.
607Guides: https://docs.g1t.sh/guides/security/secret-protection/,
608https://docs.g1t.sh/guides/security/code-scanning/,
609https://docs.g1t.sh/guides/security/supply-chain/
610
611## Deployments
612
613Part of the g1t plan ($20 a month per workspace, started by an owner
614under the workspace's Billing). No quotas: unlimited projects and
615previews (never charged); builds by the second, requests ($0.36/M), CPU
616($0.024/M ms) and custom domains ($0.12 a month each) metered from the
617first at cost + 20%, from the plan's $10 first. The trial
618never covers deployments. Then someone with admin on the repository
619turns deployments on for a project (Settings → Deployments, or Deploy on
620its overview). Production deploys from the default branch to
621`https://<project>-<owner>.g1t.page` on each push; every branch with an
622open pull request gets a preview at
623`https://<project>-git-<branch>-<owner>.g1t.page` (a fork's pull request is
624`pr-<n>`), shown on it as the check `g1t / deploy` (`g1t / deploy (<project>)`
625for a workspace's other projects). Builds and running apps
626read the project's secrets and variables available to Deployments, each
627key's Production or Preview row. Workers projects (`wrangler.jsonc`) and
628static sites build without configuration. Previews come down when the pull
629request closes and after idle days.
630Guide: https://docs.g1t.sh/guides/deployments/
631
632A repository's deployments, wherever they run, are one list: `source` is
633`api` (reported from any CI), `actions` (a g1t Actions job with
634`environment:`) or `g1t_page` (g1t.page builds, ids `dpl_…`, environments
635`production` and `preview`). Read with `GET {repo}/deployments` (filters
636`environment`, `ref`, `sha`, `task`, `state`, `source`, `creator`, `page`,
637`per_page`), `GET {repo}/deployments/{id}`, `GET {repo}/deployments/{id}/statuses`,
638`GET {repo}/environments` and `GET {repo}/environments/{environment}`
639(`deployments:read`, Read role). Report from a CI with
640`POST {repo}/deployments` (`ref`, optional `environment` (default
641`production`), `sha`, `task`, `description`, `payload`, `state`,
642`environment_url`, `log_url`), then
643`POST {repo}/deployments/{id}/statuses` with `state` (`queued`,
644`in_progress`, `success`, `failure`, `error`, `inactive`) and
645`environment_url` (`deployments:write`, Write role). A success makes the
646environment's older successful deployments `inactive` unless
647`auto_inactive: false`. Each status sets the commit check
648`deploy / <environment>`, which a ruleset's `required_deployments` rule can
649require. A g1t Actions job with `environment:` (or `{name, url}`) reports
650by itself, one deployment per run and environment; `deployment: false`
651opts out. MCP: the `workflow` tool's `list_deployments`, `get_deployment`,
652`create_deployment`, `deployment_statuses`, `create_deployment_status`,
653`list_environments`, `get_environment`. Webhooks: `deployment.created`,
654`deployment_status.created`. Guide: https://docs.g1t.sh/guides/deployments-api/
655
656## Search
657
658`GET https://api.g1t.sh/search?q=<query>&type=<type>` (MCP: `search`, action `code`, the default)
659searches all of g1t: repositories (name, description, topics, README), code
660on default branches, issues, pull requests, people and workspaces. No token
661needed for public results; with one, private results the token's person
662can read are included (their workspaces' repositories, and those they were
663given a role on), checked against current membership and roles. `type` is
664`repositories`, `code`, `issues`, `pulls` or `people` (worked out from the
665qualifiers when left out); `page` and `per_page` (at most 50) page through.
666The query takes words, `"exact phrases"`, `-word` to leave out, and
667`repo:owner/name`, `org:<workspace>`, `language:<lang>`, `path:<prefix or
668*.glob>`, `is:issue`, `is:pr`, `is:open`, `is:closed`, `is:merged`,
669`author:<username>`, `label:<label>`. Code search matches any run of three
670characters or more; vendored directories, lockfiles, binaries and files
671over 512 KB are not indexed. Results give `counts` per type and each hit's
672`snippet` or code `lines` as parts with `highlight`. On the site:
673`https://g1t.sh/search?q=`, ⌘K, and `https://g1t.sh/explore` for public
674projects by activity, language (`?language=`) and topic (`?topic=`).
675The `search` tool's `context` action stays the search of one workspace's
676context hub. Guide:
677https://docs.g1t.sh/guides/search/
678
679## Facts
680
681- API base: `https://api.g1t.sh`. `GET /` lists the main URLs as templates;
682 every operation is in the OpenAPI document.
683 Auth: `Authorization: Bearer g1t_…`. Public data needs no token. Errors are
684 `{"error": {"code": "…", "message": "…"}}` with codes `unauthenticated`
685 (401), `payment_required` (402, when the plan or a limit refuses compute),
686 `forbidden` (403, with `needed_scope` when the token lacks a
687 scope), `not_found` (404), `conflict` (409), `invalid` (422). Each
688 operation's scope is `x-scope` in the OpenAPI document. The full description is at https://api.g1t.sh/openapi.json.
689- Git remote: `https://g1t.sh/{workspace}/{repo}.git`. In API paths,
690 `{owner}` is the workspace. Pull request forks:
691 `https://g1t.sh/pulls/{pull_request_id}.git`. SSH is not available.
692- Limits: 1 GB per repository, 32 MB per file, 100 MB per push. Every
693 current limit, why it exists and the workaround:
694 https://docs.g1t.sh/about/limitations/
695- Forgotten password: https://g1t.sh/forgot (the person does this, in a
696 browser).
697- Times are RFC 3339 in UTC.
698- OAuth 2.1 for applications: metadata at
699 `https://api.g1t.sh/.well-known/oauth-authorization-server`; authorization
700 code with PKCE (S256), public clients, dynamic registration.
701- A pull request whose required checks have not passed (failed, still
702 running, or not reported yet) is refused a merge with `409`, saying
703 which; where the repository allows bypassing them
704 (`allow_ignoring_checks`), someone who can merge can send
705 `{"ignore_checks": true}`. Checks that are not required never hold a
706 merge. With the merge queue on, the workflows behind required checks
707 need `merge_group` in their `on:`.
708- Landing fast-forwards the default branch: g1t makes no merge commit on
709 main. Bringing a pull request up to date makes a merge commit on its own
710 branch.
711- Pricing (https://g1t.sh/pricing): the forge is free. One plan, g1t, at
712 $20 a month per workspace with unlimited members, includes $10 of usage
713 at cost + 20% (unused does not roll over). Compute needs the plan or a
714 card check (never charged); the $5 trial needs a credit or debit card,
715 not a prepaid one. No quotas on the plan: everything is metered from the
716 first unit at cost + 20%, and only the spend limit stops work. Every
717 workspace has 1 GB of private storage and 50,000 git operations a month
718 free; past them, the plan pays ($0.60/GB-month, $0.18/1,000) and a free
719 workspace is held (pushes to private repositories stop; git slowed to 60
720 an hour). Limits: $100 in a
721 paid workspace's first month, rising as payments clear; owners set a
722 spend limit, prepay, or ask with Raise my limit. Caps: $2 a run and $10
723 an issue by default. A spend spike pauses new compute until an owner
724 chooses Keep going or Stop (`/<workspace>/-/billing`). Audit log: 90 days
725 on every plan.
726
727## More
728
729- [Quickstart](https://docs.g1t.sh/quickstart/)
730- [How g1t works](https://docs.g1t.sh/concepts/overview/)
731- [Search and Explore](https://docs.g1t.sh/guides/search/)
732- [g1t's agent](https://docs.g1t.sh/guides/working-with-g1t/)
733- [Outcomes and plans](https://docs.g1t.sh/guides/outcomes/)
734- [Talking to agents](https://docs.g1t.sh/guides/talking-to-agents/)
735- [Bring your own agent](https://docs.g1t.sh/guides/bring-your-own-agent/)
736- [The merge queue](https://docs.g1t.sh/guides/merge-queue/)
737- [Sessions and why-blame](https://docs.g1t.sh/guides/why-blame/)
738- [Forks and branches](https://docs.g1t.sh/concepts/forks/)
739- [Accounts and sign-in](https://docs.g1t.sh/guides/authentication/)
740- [Workspaces and tokens](https://docs.g1t.sh/guides/workspaces/)
741- [Access and roles](https://docs.g1t.sh/guides/access-and-roles/)
742- [Teams](https://docs.g1t.sh/guides/teams/)
743- [CODEOWNERS](https://docs.g1t.sh/guides/codeowners/)
744- [Managing a repository](https://docs.g1t.sh/guides/managing-repositories/)
745- [Integrations](https://docs.g1t.sh/guides/integrations/)
746- [Model providers](https://docs.g1t.sh/guides/models/)
747- [AI Gateway](https://docs.g1t.sh/guides/ai-gateway/)
748- [Webhooks](https://docs.g1t.sh/guides/webhooks/)
749- [GitHub Actions](https://docs.g1t.sh/guides/actions/)
750- [Self-hosted runners](https://docs.g1t.sh/guides/self-hosted-runners/)
751- [Usage and billing](https://docs.g1t.sh/guides/usage-and-billing/)
752- [Git](https://docs.g1t.sh/guides/git/)
753- [MCP tools](https://docs.g1t.sh/reference/mcp/)
754- [API reference](https://docs.g1t.sh/reference/api/)
755- [What g1t can't do yet](https://docs.g1t.sh/about/limitations/)
756- [An open letter to Cloudflare](https://docs.g1t.sh/about/open-letter-to-cloudflare/)
757- [Source](https://g1t.sh/flagon-io/g1t), MIT licensed
758
759## Help, status and policies
760
761- [Status](https://status.g1t.sh/): whether each part of g1t is working now, 90 days of uptime, and incidents; the same as JSON at https://status.g1t.sh/status.json
762- [Support](https://g1t.sh/support): where to get help (hey@flagon.io)
763- [Security](https://g1t.sh/security): how g1t protects code and accounts, and responsible disclosure (hey@flagon.io, https://g1t.sh/.well-known/security.txt)
764- [Policies](https://g1t.sh/policies): [Terms of Service](https://g1t.sh/policies/terms), [Privacy Policy](https://g1t.sh/policies/privacy), [Acceptable Use](https://g1t.sh/policies/acceptable-use), [Refunds and Cancellation](https://g1t.sh/policies/refunds), [Subprocessors](https://g1t.sh/policies/subprocessors)
765- g1t is made by Flagon, Inc. (https://www.flagon.io)