Docs
Download

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.

Updated
Reviewed

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:

  1. 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.
  2. Your global default. If you've set a default provider in settings and it covers the project's remote, Daintree uses it.
  3. 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:

  1. 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.
  2. Read issues and pull requests. Browse and search them in a panel, with CI status and repository stats, without leaving the workspace.
  3. 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 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.

Over MCP, only reads are reachable, and only some of them: forge.getPR, forge.listPRs, forge.getIssue, forge.listIssues and forge.getCIStatus sit in the assistant's Full tool set. Writes and navigation are on no tier, so no agent merges a PR or closes an issue through Daintree. The Assistant drafts an issue and hands it to you to file.

Warning
External API-key MCP clients do not expose forge tools. The forge reads above are available only to the in-app Daintree Assistant and agent panes at the Full tool set. See the MCP server for the external tool list.

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.

The GitHub provider declares these capabilities: 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.

For implementation details, read the built-in GitHub provider. A project plugin can contribute companion actions and UI around that integration; see Project Plugins.