# Your providers, your tokens, one connection each CrewWork connects to GitHub, GitLab.com, Bitbucket Cloud, and Jira Cloud through provider-native OAuth or a direct API token, one connection per provider per organization. Each connection appears in the workbench’s Source Control surface, where the same lifecycle described in [How It Works](https://crewwork.ai/how-it-works/) picks it up. ## Four providers, each connected on its own terms GitHub, GitLab.com, and Bitbucket Cloud are full source-control connections: CrewWork lists repositories, clones them, and pushes to them. Jira Cloud is issue-tracking only, with no repository or code hosting behind it. ### GitHub Repository listing, clone, push, native issue sync, and pull request authoring. GitHub is the only provider where CrewWork opens pull requests today, and the only provider with automatic PR review comments (see below). ### GitLab.com Repository listing, clone, direct push, and issue plus merge request sync. Multi-segment subgroup paths (group/subgroup/project) are supported, not just top-level projects. Locked to the public gitlab.com API: self-hosted GitLab instances are not supported. ### Bitbucket Cloud Repository listing, clone, direct push, and issue plus pull request sync, at the standard owner/repo path shape. Locked to the public Bitbucket Cloud API: Bitbucket Server and Data Center are not supported. ### Jira Cloud Native Jira issue keys (like PROJ-123) sync as external issues. Jira is not a code hosting provider, so there is no repository, clone, or push support. Must be a Jira Cloud site (an atlassian.net origin): Jira Server and Data Center are not supported. A database-enforced unique constraint gives every organization exactly one connection per provider (one GitHub connection, one GitLab connection, one Bitbucket connection, one Jira connection), while letting all four coexist for the same organization. Connections belong to the organization, not the individual who created them. See [Organizations & Teams](https://crewwork.ai/organizations/) for how tenancy and access control work across a workspace. ## OAuth for one click, tokens for self-hosted operators Not every operator wants to register an OAuth app before connecting a provider. CrewWork supports both paths as first-class citizens, not one as a workaround for the other. ### Provider-native OAuth A one-click connect flow for GitHub, GitLab.com, Bitbucket Cloud, and Jira Cloud, each using its own OAuth app rather than a shared bridge. Refresh tokens are encrypted at rest and rotate automatically on every use, and the OAuth state binds the initiating user, organization, and provider so a connection can never land in the wrong place. ### API-token connections A first-class path for self-hosted operators: connect GitLab, Bitbucket, or Jira with a personal or API access token and skip OAuth app registration entirely. GitLab accepts a token on its own; Bitbucket and Jira pair the token with the account email tied to it. ### Account sign-in is provider-neutral too Sign-in identity is separate from your organization’s source connections. You can sign in with GitHub, GitLab.com, or Bitbucket Cloud OAuth, one identity per provider, linkable to the same account from Settings; Jira Cloud is connection-only. ## Merge requests and pull requests sync as first-class objects External-issue sync understands each provider on its own terms. GitLab merge requests and Bitbucket pull requests sync alongside native issues, so HotFix triage and linking see the same review objects your team does. Provider Native issues Change requests GitHub Issues Pull requests, authored and reviewed by CrewWork GitLab.com Issues Merge requests, synced as external issues Bitbucket Cloud Issues Pull requests, synced as external issues Jira Cloud Issue keys (like PROJ-123) Not applicable: no code hosting On GitLab.com and Bitbucket Cloud, CrewWork pushes branches directly and reads and syncs issues and merge or pull requests as external issues. It does not open merge requests on GitLab or pull requests on Bitbucket. Authoring and reviewing pull requests remains GitHub-only today. One nuance for Bitbucket Cloud: issue sync depends on the repository’s built-in issue tracker being enabled. If a workspace administers issues elsewhere, for example through a connected Jira site, and has Bitbucket’s native tracker turned off, CrewWork skips issue sync for that repository and keeps syncing pull requests. ## Every GitHub pull request gets reviewed automatically GitHub is where CrewWork’s review automation goes deepest: a default-on webhook path turns every open or updated pull request into a reviewed one, with evidence posted directly to the PR itself. ### Automatic review on open and update Every GitHub pull request that is opened or updated with new commits automatically queues an AI code review. It is on by default, and can be turned off globally, per review domain (HotFix, Platform Self-Repair, suggestions, diagnostics), or per project. Reviews are idempotent, so a redelivered webhook never queues a duplicate. ### Ownership and risk evidence, posted to the PR The review comment reports CODEOWNERS resolution status and any changed paths with no listed owner, the PR’s owning project team plus any linked service-catalog owner teams, and a blast-radius read on the change: risk level, confidence score, index freshness, and counts of affected files, routes, tests, and workers. ### Complete file enumeration, even on large PRs Review coverage paginates up to 3,000 changed files instead of stopping at the first page, preserves original filenames across renames, and raises an explicit error rather than silently reviewing an empty file list when GitHub is unreachable. ### Quality gate status on the same commit A five-part quality gate (tests, coverage, security, code health, and live preview quality) posts as its own GitHub commit status alongside the review comment. Defaults require 80 percent minimum line coverage, a health score of 70 or higher, and zero new critical or high severity findings. See [Testing & Quality Gates](https://crewwork.ai/quality/) for how each part is scored. ## Let your own tools read a project too CrewMate exposes a spec-compliant Model Context Protocol endpoint on your CrewWork deployment: a single JSON-RPC route implementing the MCP 2025-11-25 lifecycle (initialize, tools/list, tools/call) over stateless Streamable HTTP. Any MCP-capable external client, including Claude Desktop and Cursor, can connect to a project and read files, search code, and inspect git status without going through the workbench at all. Every call rechecks the connecting actor’s live project-read permission. Requests authenticate with a session cookie or a scoped CrewWork API key, and the endpoint validates the request Origin and enforces its own request-size and rate limits, independent of the rest of the API. All six tools are read-only: there is no write path and no shell access through MCP, the same read-only posture as the workbench’s code reader. ### Six tools, each explicitly bounded - project.summary: up to 40 top-level entries - workspace.list\_files: up to 200 entries per call - workspace.read\_file: 1 to 500 lines, up to 60,000 characters - workspace.search: 1 to 200 results per call, 60-second command timeout - git.status: up to 200 entries per path category, with true totals reported - git.diff: up to 100 paths per call, output capped and time-bounded ## Sentry is a separate, dedicated integration Source providers connect your code. Sentry connects your running application’s errors to HotFix, CrewWork’s error-to-fix remediation lane, with its own triage, validation, and STAGED review flow. [See the Sentry integration](https://crewwork.ai/sentry/) ## Bring your next piece of work. Discuss what you want to build, repair, or improve, along with your deployment needs and access to CrewWork. [Discuss your project](https://crewwork.ai/about/#access) [Truth & Trust Engineering](https://crewwork.ai/trust-engineering/) Or [view the architecture](https://crewwork.ai/architecture/) for the full technical picture. --- Canonical page: https://crewwork.ai/integrations/