Connect the tools your team already uses
Connect GitHub, GitLab.com, Bitbucket Cloud, or Jira Cloud to bring repositories and issues into your work. Connections belong to your organization, and repository state is available in the selected project. How It Works shows how work picks it up from there.
| Provider | Sign-in | Connection |
|---|---|---|
| GitHub | yes | OAuth |
| GitLab.com | yes | OAuth or API token |
| Bitbucket Cloud | yes | OAuth or API token |
| Jira Cloud | no | OAuth or API token |
Four providers, each connected on its own terms
GitHub, GitLab.com, and Bitbucket Cloud are full source-control connections; Jira Cloud is issue tracking only.
| Provider | Capabilities |
|---|---|
| GitHub | Repository listing, clone, push, native issue sync, and pull request authoring with automatic review comments (see below). |
| GitLab.com | Repository listing, clone, push, issue and merge request sync, and change review, including multi-segment subgroup paths. |
| Bitbucket Cloud | Repository listing, clone, push, issue and pull request sync, and change review for supported repositories. |
| 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. |
All four are locked to their public cloud APIs: self-hosted GitLab, Bitbucket Server and Data Center, and Jira Server and Data Center are not supported.
Each organization can have one connection per provider. Connections belong to the organization, not the individual who created them. See Organizations & Teams 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.
- 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.
- OAuth state
- Binds the initiating user, organization, and provider to the connection request.
- API token
- Connect GitLab, Bitbucket, or Jira with a personal or API access token and skip OAuth app registration. GitLab accepts a token on its own; Bitbucket and Jira pair it 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 runtime-error 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 and reviewable |
| Bitbucket Cloud | Issues | Pull requests, synced and reviewable |
| Jira Cloud | Issue keys (like PROJ-123) | Not applicable: no code hosting |
On GitLab.com and Bitbucket Cloud, CrewWork can push branches and review existing merge or pull requests; it does not open them. Pull request authoring is available on GitHub. Publication depends on the connected provider and its permissions.
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.
Bring review evidence to the change
CrewWork can review change requests on GitHub, GitLab.com, and Bitbucket Cloud and publish findings to the provider. On GitHub, eligible pull requests can also enter review automatically through a configurable webhook policy.
- queue eligible GitHub pull requests opened or updated with new commits queue a review when the applicable policy is enabled
- enumerate up to 3,000 changed files, renames preserved; an unreachable GitHub raises an error rather than reviewing an empty list
- evidence review findings and available ownership, impact, and quality evidence help a person assess the change
- gate on GitHub, GitLab.com, or Bitbucket Cloud, the five-part quality gate can post its own commit status; thresholds are on Testing & Quality Gates
- decide a person reads the evidence and decides whether to merge
Let your own tools read a project too
CrewMate exposes a spec-compliant Model Context Protocol endpoint on your CrewWork deployment: one JSON-RPC route implementing the MCP 2025-11-25 lifecycle over stateless Streamable HTTP. Any MCP client, including Claude Desktop and Cursor, can read files, search code, and inspect git status on a project without the workbench.
- auth
- A session cookie or a scoped CrewWork API key; live project-read permission is rechecked on every call, the request Origin is validated, and the endpoint enforces its own size and rate limits.
- posture
- Read-only: no write path and no shell access, the same posture as the workbench’s code reader.
- 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
See whether CrewWork fits your work.
CrewWork is built and running, and not yet generally available.
- worth discussing
- The errors and backlog you would hand off
- Where your source has to stay
- The evidence you would need to trust a change