GitHub App & authentication
Sign-in, the GitHub App, per-user git credentials, and how reconnection works when access breaks.
darting.dev is git-native, so authentication and repo access are the same problem. Signing in with GitHub solves both at once.
Sign in once
You sign in with GitHub, and the same login grants the repo scope — so your sign-in is the git credential used to clone and push private repositories. There's no second "connect your repo" step after you land, and no personal token to paste before your first thread can boot a sandbox.
Two credential paths
| Path | When to use it |
|---|---|
| GitHub App install | The recommended path. You choose exactly which repositories it can reach, and access is managed on GitHub's side rather than in a token you have to rotate by hand. |
| Classic personal-access token | The fallback, for cases the App install doesn't cover. |
Both are held per user. Whichever path you use, adding a project starts from the repositories your own credential can see — see projects & setup for what happens next.
Where tokens live
Git tokens are stored server-side and are never exposed to the browser. Nothing that reaches your client can be replayed to push code.
They're also scoped to a person, not to a team or a bot. Every push, every branch, and every pull request an agent opens on your behalf happens with your credentials, so your repo's history and its protection rules read exactly the way they would if you'd typed the commands yourself. That per-user boundary holds even inside a shared project — see roles & permissions.
When access breaks
Credentials expire, tokens get revoked, and someone eventually uninstalls the App from an organization. When that happens, the failure surfaces as a reconnect banner in the workspace with the remediation path attached — rather than a thread that mysteriously can't push, or an agent burning a turn on a git error it can't fix.
The banner tells you which credential lapsed and how to restore it, so the fix is a reconnect rather than a debugging session.
Webhooks from your repo
Access can flow the other way too. Point a repository's webhook at darting.dev and issue or PR comments are routed into that project's chat agent, so a comment on a bug report can start a thread that fixes it. When a webhook secret is set, payload signatures are verified, so only your repo can drive that entrance.
Because inbound payloads are external input, they're treated as data to read, not as instructions to follow — integrations covers that boundary along with inbound hooks and the event spine.
Your app's own secrets are separate
Your GitHub credential is what lets a sandbox clone and push. Everything your app needs to run — API keys, database URLs, third-party tokens — you supply as project secrets, which are manager-gated and injected into every sandbox; see secrets & environment.