[FEATURE] Claude Tag: support self-managed / on-prem GitLab repositories

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

• [x] I have searched existing requests and this specific feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

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":

1. 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.
2. 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

• #12346 — broad GitLab integration (repo connection, MRs, mobile)
• #21527 — GitLab support for the Slack integration
• #54660 — GitLab plugin configurable base URL for self-hosted instances
• #70561 — SSH URL format for downloading plugins from internal GitLab