Updated to clarify this is about Claude Tag — the Slack-based agentic teammate Anthropic launched on June 23, 2026 (powered by Opus 4.8, with async task execution that can run coding work over hours/days; it replaces the previous "Claude in Slack"). The original draft mistakenly described the GitHub @claude Action; the ask below is specifically about Claude Tag's repository connections.
Preflight Checklist
Problem Statement
Claude Tag can be assigned long-running coding tasks from Slack and execute them autonomously against a connected repository (read code, make changes, open a PR). Today that connection is GitHub-oriented. Teams running self-managed / on-prem GitLab — air-gapped or VPC-internal instances on a custom domain (e.g. gitlab.company.internal), not gitlab.com — have no way to point Claude Tag at their repos.
Two things make this specifically an on-prem problem, not just "add GitLab":
- Reachability — the instance lives behind the corporate firewall with no inbound path from Anthropic's cloud. A hosted agent simply cannot open a connection to it.
- Data residency — these orgs self-host because source code is not allowed to leave their network. Any solution that clones the repo to Anthropic-side infrastructure is a non-starter for them.
This disproportionately blocks the exact audience Claude Tag targets: large/regulated enterprises on Team/Enterprise plans, who are also the ones most likely to self-host GitLab.
Proposed Solution
The crux is reaching a repo behind the firewall without inbound network changes or shipping code out of the customer's network. Concretely:
1. A customer-deployed connector (the key piece). Ship a lightweight connector/runner the customer installs inside their network (Docker image / Helm chart, similar to a GitLab self-hosted runner or the existing remote-MCP pattern). It holds an outbound-only, authenticated control channel to Claude Tag — so no inbound firewall holes, no exposing GitLab to the internet. Claude Tag sends task intents; the connector performs the GitLab API calls and (optionally) hosts the execution sandbox locally. This is the standard, security-team-approvable shape for on-prem AI access and resolves both reachability and residency.
2. Reuse the GitLab MCP server as the API surface. A GitLab MCP server already exists; give it a configurable base URL + private CA bundle (see #54660) and run it behind the connector. Claude Tag then talks GitLab through MCP tools (issues, MRs, files, pipelines) rather than bespoke integration code — smaller surface area, already permission-gated.
3. Execution stays in-network (residency). For "assign a task, step away" runs, the coding sandbox (clone, edit, test, build) runs on the connector inside the customer VPC; only diffs/MR metadata and Claude's reasoning transit the control channel. Configurable so residency-strict customers keep the working tree local.
4. Auth & scoping. Project/Group Access Token or PAT with api scope, stored in the customer's own secret store and used only by the connector. Respect Claude Tag's existing per-channel tool/data controls so a given Slack channel only reaches the GitLab projects it's scoped to. Full audit log of connector actions.
5. MR-workflow parity. Branch, push, and open/update Merge Requests (the GitLab equivalent of the PR flow), including pipeline status and review comments.
Phasing (so it can land incrementally):
- MVP — connector + GitLab MCP with configurable base URL; read issues/MRs/files and post comments (read-mostly, lowest risk to approve).
- v1 — branch/push/open-MR via the connector.
- v2 — full async task execution with the sandbox running in-network.
# example: customer-side connector config
gitlab:
base_url: https://gitlab.company.internal
ca_bundle: /etc/ssl/corp-root.pem
token_env: GITLAB_PAT # api scope; lives only in the customer's secret store
execution:
sandbox: in_network # working tree never leaves the VPC
control_channel:
mode: outbound_only # no inbound firewall rules
Why this matters — GitLab adoption (context)
GitLab is one of the most-used platforms among the enterprises on Anthropic's Team/Enterprise plans:
- 50%+ of the Fortune 100 are GitLab customers.
- 50M+ registered users worldwide.
- ~40,700 companies use GitLab as their source-code-management tool (third-party tech-adoption trackers).
- GitLab FY2026: 10,682 base customers, 1,456 at ≥$100K ARR, and 155 at ≥$1M ARR (up from 123 a year earlier) — large enterprises standardizing on it, many self-managed.
On-prem/self-managed GitLab is a default in finance, healthcare, government, and defense — the orgs least able to use cloud Git hosting and most able to buy Claude Tag at scale.
(Adoption figures are from GitLab's FY2026 10-K and public third-party trackers; cited as approximate context, not exact internal numbers.)
Related (distinct) existing requests
Preflight Checklist
Problem Statement
Claude Tag can be assigned long-running coding tasks from Slack and execute them autonomously against a connected repository (read code, make changes, open a PR). Today that connection is GitHub-oriented. Teams running self-managed / on-prem GitLab — air-gapped or VPC-internal instances on a custom domain (e.g.
gitlab.company.internal), notgitlab.com— have no way to point Claude Tag at their repos.Two things make this specifically an on-prem problem, not just "add GitLab":
This disproportionately blocks the exact audience Claude Tag targets: large/regulated enterprises on Team/Enterprise plans, who are also the ones most likely to self-host GitLab.
Proposed Solution
The crux is reaching a repo behind the firewall without inbound network changes or shipping code out of the customer's network. Concretely:
1. A customer-deployed connector (the key piece). Ship a lightweight connector/runner the customer installs inside their network (Docker image / Helm chart, similar to a GitLab self-hosted runner or the existing remote-MCP pattern). It holds an outbound-only, authenticated control channel to Claude Tag — so no inbound firewall holes, no exposing GitLab to the internet. Claude Tag sends task intents; the connector performs the GitLab API calls and (optionally) hosts the execution sandbox locally. This is the standard, security-team-approvable shape for on-prem AI access and resolves both reachability and residency.
2. Reuse the GitLab MCP server as the API surface. A GitLab MCP server already exists; give it a configurable base URL + private CA bundle (see #54660) and run it behind the connector. Claude Tag then talks GitLab through MCP tools (issues, MRs, files, pipelines) rather than bespoke integration code — smaller surface area, already permission-gated.
3. Execution stays in-network (residency). For "assign a task, step away" runs, the coding sandbox (clone, edit, test, build) runs on the connector inside the customer VPC; only diffs/MR metadata and Claude's reasoning transit the control channel. Configurable so residency-strict customers keep the working tree local.
4. Auth & scoping. Project/Group Access Token or PAT with
apiscope, stored in the customer's own secret store and used only by the connector. Respect Claude Tag's existing per-channel tool/data controls so a given Slack channel only reaches the GitLab projects it's scoped to. Full audit log of connector actions.5. MR-workflow parity. Branch, push, and open/update Merge Requests (the GitLab equivalent of the PR flow), including pipeline status and review comments.
Phasing (so it can land incrementally):
Why this matters — GitLab adoption (context)
GitLab is one of the most-used platforms among the enterprises on Anthropic's Team/Enterprise plans:
On-prem/self-managed GitLab is a default in finance, healthcare, government, and defense — the orgs least able to use cloud Git hosting and most able to buy Claude Tag at scale.
(Adoption figures are from GitLab's FY2026 10-K and public third-party trackers; cited as approximate context, not exact internal numbers.)
Related (distinct) existing requests