Code Forge

Connect Daintree to a code forge: provider resolution, tokens, the issues and PR panel, CI status, bulk worktree creation, and the forge actions agents can call.

Reviewed Aug 18, 2026

Forge providers

Daintree used to integrate only with GitHub. That integration is now a general forge provider model. A forge is the platform layer that sits on top of git: issues, pull requests, reviews, CI status, releases, and authentication.

GitHub is the provider that ships today, and everything on this page describes it. The structure underneath is provider-neutral. Issue creation, "assign to me", worktree actions, commit-author avatars and the toolbar counts all route through a typed contract rather than calling GitHub directly, so a second provider slots in without a second code path in the app.

Note

A forge provider cannot be installed as a third-party plugin. Providers must be in-process built-ins that ship inside the app bundle, because the parts of the contract Daintree calls on the hot path (remote parsing, URL building, push-error classification) are synchronous, and an out-of-process .dntr plugin can only answer across an async message port. Calling registerForgeProvider from a worker-hosted plugin logs a warning and returns a no-op. Plugins extend the forge experience in other ways (the built-in GitHub provider itself contributes a file-decoration provider for diff review), but they cannot register a forge. See the plugin system for what plugins can and cannot do.

How Daintree chooses a provider

When you open a project, Daintree picks a forge provider by checking three things in order:

A per-project override. If you've pinned this project to a specific provider, that wins, and it is searched against the whole registry rather than only the providers that match the remote's hostname.
Your global default. If you've set a default provider in settings and it covers the project's remote, Daintree uses it.
Hostname matching. Otherwise Daintree reads the git remote URL and matches its hostname against the registered providers. A github.com remote resolves to the built-in GitHub provider.

Hostname matching is exact after lowercasing and stripping a leading www.. There are no wildcards, and there is no fuzzy fallback.

Warning

Both explicit tiers fail closed. An override naming a provider that is not registered resolves to no provider at all: it does not fall through to hostname detection. Neither does a global default that doesn't cover the project's remote. The visible symptom is a dark toolbar with no counts, which is the intended signal: a silently substituted provider would point issue and PR writes at the wrong repository.

What a connection gets you

Connecting a forge does three things, and each has its own page:

Connect and authenticate. Pick a provider, supply a token with the right scopes, and confirm Daintree accepted it. Start here, because nothing below works until this does.
Read issues and pull requests. Browse and search them in a panel, with CI status and repository stats, without leaving the workspace.
Create and link worktrees. Turn an issue or a pull request into a branch and a checkout, one at a time or in bulk, and keep the link between the two afterwards.

What agents can do with the forge

The forge is not just a panel. Daintree exposes it as a set of 35 forge.* actions, so an agent working in a worktree can read and act on the same data you can:

Reads: repository stats, issue and PR listing and detail, issue comment threads, CI roll-up status, and per-check detail. Listing takes page size, sort and direction, and returns either a summary or a full view; an unrecognized filter is rejected rather than silently dropped, so an agent finds out it asked for something impossible instead of acting on a wrong result set.
Per-check CI detail: an agent can see which check failed, not just that the roll-up is red, which is the difference between "CI is broken" and "the lint job failed on two files".
Issue writes: create, close, reopen, edit, comment, add and remove labels, assign and unassign.
PR writes: create, close, reopen, merge, edit, comment, convert to draft, mark ready for review.
Review writes: approve, request changes, dismiss a review, request reviewers.
Navigation: open an issue, PR or commit list in the browser.

Reads sit at the assistant's workbench tier. Writes and navigation sit at the system tier, so raising the tier is the deliberate act that lets an agent merge a PR or close an issue on your behalf.

Warning

External MCP clients cannot reach any forge tool. The external, API-key tool surface was cut to 25 tools, and the forge set was dropped from it entirely: reads and writes both. The reasoning is that an external agent driving Daintree over MCP is already sitting in a terminal with its own gh, and the surface has a hard size budget before third-party clients start silently truncating it. Forge tools remain fully available to the in-app Daintree Assistant, which no client cap applies to. If you have read that Daintree offers "forge write operations over MCP", that is true only of the in-app agent surface. See the MCP server for the authoritative tool list and the tier model.

Adding another forge

A second forge (GitLab, Gitea, Bitbucket, a self-hosted server) is a built-in provider, not something you install. Everything around it is already provider-neutral: resolution, the settings section and credential form, the toolbar counts, the worktree linkage and the forge.* actions all route through one contract.

What a provider has to implement is the capability set the GitHub provider declares: issues, pulls, reviews, required-checks, draft-prs, assignees, releases, batch-branch-prs, identity, and clone. Capabilities are declared, not assumed, so the UI can hide what a given forge doesn't support rather than failing at call time.