Connect GitLab so Coworker can see what your engineering team is shipping across your GitLab projects. GitLab is a per-user (individual) connection: each person connects their own GitLab identity, and coverage grows as more people connect.
What Coworker can do with GitLab
Index the projects, merge requests, commits, notes, issues, epics and CI/CD pipelines your GitLab identity can reach
Produce a daily digest per project: what shipped, what is in review, and who did the work. Quiet projects produce nothing.
Read code, files, merge request diffs and pipeline results on demand during Deep Work, and take supported write actions (create branches, merge requests, releases, issues and comments) when a task requires it
Receive real-time updates through project webhooks for pushes, merge requests, issues, notes and pipelines
Projects become Document entities and contributors become Person entities, so the same human is one node across GitLab, Slack, Drive and your CRM. Merge requests, commits, issues and pipelines stay in the raw store and power the activity reports.
Before you start
You need an active GitLab account (gitlab.com or a self-managed instance)
If you use a personal or group access token instead of OAuth, it needs API read scope
For self-managed GitLab, you need your instance's API URL — it is part of the credential
Connect as a member
Go to the Work page at app.coworker.ai and click Data Sources.
Select GitLab under Available sources.
Complete the GitLab OAuth authorization. For self-managed GitLab, enter your instance API URL first so the OAuth flow targets the right instance.
GitLab moves to Connected.
Connect as an admin
Open Data Sources from the admin settings in Coworker and select GitLab.
Enter your GitLab API URL (required for self-managed instances) and either complete OAuth or paste an access token.
Save. Admins can also block GitLab for the workspace from Source Settings.
An admin or personal access token is accepted and joins the credential pool, but it is not a workspace-wide god credential — it only sees what its GitLab owner is allowed to see.
Good to know
Coverage is the union of what connected users can see. Private projects stay invisible until someone with access connects.
Internal projects (visible to any logged-in GitLab user) are deliberately treated as private-to-members rather than workspace-public, because "any GitLab user" is broader than your workspace.
Guest-level members cannot read repository code, so a successful project listing does not by itself prove code access.
GitLab hides email addresses more aggressively than GitHub, so person coverage grows as more users connect.
OAuth tokens are tied to the matching GitLab instance and client; personal and group tokens can expire and will need replacing.