Git hosts & authentication
Signing in, connecting GitHub, GitLab, or Bitbucket, the credential used for thread git, and one-command access to another repo.
darting.dev works with repositories on GitHub, GitLab, and Bitbucket. Signing in is not the same as granting repository access. You can sign in one way and give the app access to a repository when you add or connect one.
Signing in
Sign in with GitHub, Google, or a one-time emailed code. If you link another provider to your account, signing in with that provider's email reaches the same account. Account settings → Security lists your Sign-in methods, where you can link or unlink them; the last one cannot be removed. Companies can set up enterprise SSO through Okta, Microsoft Entra, or any OIDC provider: Continue with SSO takes a work email, an organization can require SSO for its domain, and new sign-ins can join a team automatically.
Connecting a repository
When you connect a repository, the app checks whether your credentials can reach it and offers the relevant connection paths. Project settings has a Connections tab for checking that project's access; Account settings → Connections shows the credentials attached to your account. For GitHub, a GitHub App installation can let a project reach a repository, but it does not give a person an identity for authoring pull requests.
| Credential path | Which repositories it can reach |
|---|---|
| darting GitHub App installation | Only repositories covered by that installation, on the account or organization where you installed it; select repositories on GitHub. Scoped, short-lived installation credentials are the path to prefer when App mode is available. |
| GitHub OAuth grant | Repositories your GitHub account can see, including private repositories, after you grant repo access; an organization can restrict OAuth apps. This grant also carries workflow access. |
| Classic personal access token | Repositories that token's GitHub account can see, including private repositories and other organizations when permitted, with repo scope. |
| Fine-grained personal access token | Only repositories and permissions selected when you created it. Include Contents read to read a repo and Contents write to push. |
| Operator token | Only repositories the platform operator's account can reach; don't assume it covers yours. |
In Project Settings → Connections, the GitHub access check offers Grant OAuth access or Install GitHub App when that path is available. In Account settings → Connections, use Grant repo access, Install GitHub App, or Add token. You can test access to a repository there rather than guessing which token it needs. A fine-grained token that omits the project repo may authenticate to GitHub yet still get a 403 or 404 for that repo. See projects & setup for connecting a repository.
GitLab projects connect with a GitLab access token (personal, project, or group). Projects on gitlab.com work out of the box; a team can admit its self-hosted GitLab instance to use beside it. Changes ship as merge requests, and GitLab CI jobs report as checks. Bitbucket projects connect with a Bitbucket access token (repository, project, or workspace), and Bitbucket Pipelines report as checks. Both ship through the merge queue and can Go Live like GitHub projects.
What a sandbox can do with git
The sandbox does not hold a git-host token. Git traffic to the project's own repository is authenticated at the network boundary. For that repository, the thread creator's credential is used if it can push; otherwise the project owner's credential, the App installation, or the operator credential may be used. A teammate's token is not borrowed just because they joined the thread. If a credential changes, the next git request resolves the current access; a sandbox does not need a newly pasted token.
A sandbox push may update only that thread's own branch (including its pull-request branch after it is renamed). It cannot use its credential to push main, another thread's branch, or a tag. Publishing work to the default branch happens through Ship it & pull requests, not a direct sandbox push. Normal GitHub API calls and the gh command are not automatically authenticated by the project-repo git access.
One command in another repository
A clone or fetch of a second private repository is unauthenticated by default, even if your account can read it. When a task needs that repository or a git-host API call, the agent can ask for an access window. The card leads with a plain-language reason and lets you inspect the exact command. Approve lends your own connected account for that one command; Deny runs nothing. Another command requires another approval. The project repository's branch restriction remains in place. A project member approving the card lends their own access, not the thread creator's.
For unattended GitHub API calls that cannot wait for your approval, you can instead provide a narrowly scoped GITHUB_TOKEN through the Secrets vault. It is injected for GitHub API requests, not given to the agent and not used to authenticate git for another repository. A plain Sandbox variable with that name is not a substitute for a vaulted token on GitHub's API host.
When access breaks
Tokens expire, permissions change, and an App installation can lose coverage of a repository. Check access under Project Settings → Connections; if it fails, grant OAuth access, change the App's repository selection, or update a token under Account settings → Connections. A successful sign-in by itself does not repair missing repo permissions. An organization that blocks OAuth apps may need an admin to allow the grant, or an App installation or appropriately scoped token instead.
Webhooks from your repo
Webhooks from GitHub, GitLab, and Bitbucket feed branch movement, pull-request state, checks, reviews, and deployment status back into the project. A trusted review requesting changes can start a fix turn on the matching thread; an outside review is surfaced for a person to consider instead. Payload signatures are verified. Issue and PR comments are not a general command channel to the agent; PR comments in particular are excluded from the review feed. See integrations for other ways external events enter the product.
Your app's own secrets are separate
Your git-host connection lets a thread work with its repository. It does not supply your app's database URL, third-party API keys, or production credentials. Use Sandbox and Live variables for values the app reads, or the vault when an agent should use a credential without being able to read it.