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. Repository state appears in the selected Project’s contextual Code workspace, where the same lifecycle described in How It Works picks it up.
| 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, direct push, and issue plus merge request sync, including multi-segment subgroup paths (group/subgroup/project), not just top-level projects. |
| Bitbucket Cloud | The same capabilities as GitLab.com, with pull request sync at the standard owner/repo path shape. |
| 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.
A database-enforced unique constraint gives every organization exactly one connection per provider, and 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, so a connection can never land in the wrong place.
- 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 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 syncs merge or pull requests as external issues; it does not open them. 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.
- queue every pull request opened or updated with new commits queues a review; on by default, and can be turned off globally, per review domain, or per project; a redelivered webhook never queues a duplicate
- enumerate up to 3,000 changed files, renames preserved; an unreachable GitHub raises an error rather than reviewing an empty list
- evidence the comment reports CODEOWNERS status and unowned paths, the owning teams, and a blast-radius read: risk, confidence, index freshness, and affected files, routes, tests, and workers
- gate the five-part quality gate posts its own commit status on the same commit; 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