T3 Code integrates with GitHub, GitLab, Forgejo, Gitea, Bitbucket, and Azure DevOps to clone and publish repositories, create pull requests, and review changes.
Install Git and configure authentication on the machine running your T3 Code server. For a remote environment, do this on the remote machine. After signing in, open Settings → Source Control and choose Rescan.
Install GitHub CLI 2.81.0 or newer, then sign in:
gh auth loginInstall Forgejo CLI (fj) or
Gitea CLI (tea) 0.16 or later on your T3 Code server.
Sign in with fj --host https://your-server auth add-token or tea login add.
Repeat for each server you use, including Codeberg.
T3 Code prefers a matching fj login and falls back to tea when fj is unavailable
or has no login for that server. Once an account is selected, failed actions stay on that
account. Settings shows the detected CLI. Forgejo and Gitea share one integration entry.
Servers hosted under a URL subpath, such as https://example.com/forgejo, use tea because
fj 0.6 does not preserve the subpath when checking its account.
When cloning or publishing, use a full repository URL to select a specific server.
You can use owner/repo when only one fj server is configured, or with your default tea
login when fj is unavailable or unconfigured. With multiple fj servers, use the full URL.
If you have multiple tea accounts on one server, select one with
tea login default <login-name>. Git push and clone also need Git credentials or an SSH key
for that server.
Install GitLab CLI, then sign in:
glab auth loginSet an access token in the server's environment:
export T3CODE_BITBUCKET_ACCESS_TOKEN="your-access-token"Or use an Atlassian account email and API token with read/write access to repositories and pull
requests, plus user read access (read:user:bitbucket):
export T3CODE_BITBUCKET_EMAIL="you@example.com"
export T3CODE_BITBUCKET_API_TOKEN="your-token"The access token takes precedence if both are configured. Restart the server after changing these variables.
Install Azure CLI, add the DevOps extension, and sign in:
az extension add --name azure-devops
az loginUse Add Project in the command palette (Cmd/Ctrl+K) to clone a repository. Choose a hosting
provider or paste a Git URL, then choose where to save it. GitHub repositories clone over HTTPS;
to use SSH, choose Git URL and paste the SSH clone URL. The project opens right away while the
clone runs in the background: you can write your first prompt, and sending waits until the files
are in place. A toast tracks progress and lets you cancel; if the clone fails, retry it from the
toast or from the banner above the composer.
For a local Git repository without a remote, Publish Repository creates a hosted repository,
adds it as origin, and pushes your commits. If there are no commits yet, it creates the remote;
make your first commit before pushing.
When a checkout has several remotes, pull requests, issues, and the Pull requests page use its
default repository. This is the same setting as gh repo set-default, so T3 Code and the
GitHub CLI, including agents that run gh in the checkout, use the same repository. Without a
default, T3 Code uses the upstream remote's repository, or origin's when there is no upstream.
The GitHub CLI picks the same one unless a remote is named github.
Cloning a GitHub fork keeps your fork as origin, adds the repository it was forked from as
upstream, and asks you to choose the default repository. Choose the original project when you
are cloning to contribute to it. Clones from other hosts or a plain Git URL do not get this step.
Adding an existing folder with Add Project asks the same question when its remotes point at more than one GitHub repository and no default is set. Choose Decide later to leave the default unset.
To change the default later, select the project in the Settings breadcrumb and change Default repository in the Project category; a project with several checkouts shows it under each checkout.
Use a thread's Git actions to commit, push, and create a pull request. T3 Code can generate commit messages, review titles, and descriptions from your changes.
Choose the writing style and model in Settings → Source Control. Repository conventions uses the project's instructions and recent commit subjects.
Run New thread from GitHub issue… from the command palette and search the current project's open issues by number or title. The issue's title, body, and comments are attached to a new thread draft as removable context. Nothing is sent until you write your instructions and send them.
Open Pull requests to review changes and comments, request reviewers, check out a branch, or merge. You can edit review titles and descriptions and your own comments where the host allows it. GitLab calls these merge requests.
GitHub, GitLab, and Azure DevOps support auto-merge while checks are outstanding. Commits pushed after auto-merge is on are merged too, unless the host turns auto-merge off. GitHub also supports approving waiting fork workflows and opening a revert pull request for a merged change.
GitHub sharing is off by default. In Settings → Connections → GitHub sharing (Environments on mobile), choose Read PRs or Read and act for each environment you trust to share GitHub access. Enable both the original environment and the environment answering its requests on this client. Read and act can use broader GitHub permissions than the original environment's credential; only enable it for environments you control and trust. Changing a saved endpoint or removing an environment clears its permission.
GitHub review details, linked PR status, and permitted review actions can then use another connected environment signed in to the same GitHub account. Each needs a project on that host. A connected local environment is preferred for actions and can answer slow or failed reads. Browsers and mobile clients need a paired environment to use its GitHub CLI credentials. Credentials stay on their machines. Previously verified credentials remain usable for routing for ten minutes during a GitHub outage; new credentials must be verified first. An action with an uncertain result is never automatically retried elsewhere. Listings, diffs, and checkout or PR creation from Git actions continue to use the project's environment.
For Azure DevOps, use the host website to change comments. Bitbucket does not support reopening a declined pull request.
Tick a file off in the Code tab once you have read it and it collapses; the toolbar keeps a running count. A tick belongs to the pull request rather than to a commit, so scoping the tab to a single commit keeps them. A file pushed to after you cleared it comes back marked Changed.
On GitHub these are GitHub's own viewed marks, so a review carries between T3 Code and github.com in either direction. Forgejo, GitLab, Bitbucket, and Azure DevOps expose no record T3 Code can read, so the server you are connected to keeps them instead: they follow you across the apps connected to that server, but the host's own site will not show them, and the count reads viewed in T3 Code.
The Code tab is a web and desktop surface. The mobile app reports a pull request's status but does not show its diff, so marks are made and read on web and desktop.
For GitHub pull requests:
- Checks separates checks required by repository policy from optional ones, including required checks that have not reported yet. When rules require an out-of-date branch to be updated before merging, it explains why and offers the update methods you can use. Auto-merge waits for that update; it does not perform it.
- Images stored in the repository display in pull request descriptions, including for private repositories. A relative image path is read from the pull request's head, so it displays even when that branch is not checked out.
- On web and desktop, pull request links in descriptions and comments open another tab beside the same thread when the linked repository is available in that environment. Cmd/Ctrl-click opens the link in your browser.
- With several remotes, the Pull requests page uses the default repository.
Changed files in a pull request's Code tab and a thread's diff panel start collapsed. To open them
expanded, set Default diff file state to Expanded in Settings → General. Generated files,
such as lockfiles and files the repository marks linguist-generated, still start collapsed until
you open them.
Proactive panels is on by default: a newly linked review opens automatically, and agent work that changes files switches to its diff when the turn completes. Turn it off in Settings → General.
- Not authenticated: run the provider's login command on the server, then rescan. For Bitbucket, confirm the running server received the environment variables.
- GitHub sign-in cannot be verified: update GitHub CLI to at least 2.81.0.
- Push fails despite a connected account: check the Git remote's credentials. SSH and HTTPS remotes can require separate setup from the hosting provider's API access.
- GitHub operations fail unexpectedly: when GitHub reports a disruption, web and desktop show the affected services in the sidebar while you have a GitHub project. Select the notice to open GitHub Status. Turn these alerts off under GitHub in Settings > General > Outage alerts.
- A review cannot load: open it on the host website while resolving connectivity, permissions, or rate limits.
A thread can hold several pull requests, including reviews from another repository on the same host.
Use Link pull request in the command palette or Linked pull requests panel, or right-click a
pull request link in the conversation. Creating a pull request from Git actions links it automatically.
Agents can link their pull requests with the link_pull_request tool.
Use Link this PR in a branch-detected badge's tooltip to keep it with the thread. From a review on the Pull Requests page, Link to thread lets you search for an active thread. The review header also lists the threads that link to it, including archived threads, so you can return to their context.
Thread badges show a stack's layer count or the current review number with a count of additional links. On mobile, the Git overview lists linked reviews and their stacks; tap a review to open it. Linking and unlinking are available in the web and desktop clients.
The Linked pull requests panel lists every review and groups stacks. Unlink a review from its row menu. An unlinked stack layer stays out of later syncs. Open linked reviews refresh on the server; closed reviews refresh periodically so reopening one on the host is detected. Merged reviews refresh when requested. With Auto-settle merged threads enabled, a thread can settle after every linked review is terminal. An open or unsynced link keeps it active.
Cross-repository links use a project on the same host. Azure DevOps reviews require a project checked out from the matching organization and repository.
The Pull Requests page shows each PR's position in its GitHub stack. Open the stack badge in a review to navigate its layers. Merge stack submits the selected pull request and every unmerged layer below it to GitHub together, respecting branch rules and merge queues. The confirmation shows the scope and merge strategy. GitHub rebases the remaining stack after merging.
Rebase stack updates remote branches from bottom to top without changing your local checkout. It can rewrite history and restart checks. If a layer fails, earlier updates remain; resolve that layer before retrying. GitHub may require manual conflict resolution after a lower layer is amended, even when its changes look independent. Stack actions require an environment that supports them.