One read of Claude Documentation

 ### Adding a request header
 
 1. In the Add custom connector dialog, open **Request headers**.
-2. Select a header name from the list, or enter one manually. Claude accepts a fixed set of standard authentication and routing header names such as `authorization`, `x-api-key`, and `x-auth-token`. Header names are restricted to this allowlist for security reasons: each name is reviewed before Claude will send it to a third-party server, which prevents connector configuration from being used to send arbitrary header names. To request an addition to the allowlist, contact your Anthropic representative.
+2. Select a header name from the list, or choose **Custom header** to enter a different name. The list offers standard authentication and routing header names such as `authorization`, `x-api-key`, and `x-auth-token`, which every connector can use. Anthropic reviews and approves each custom header name before Claude will send it to a third-party server, which prevents connector configuration from being used to send arbitrary header names. If you enter a header name that isn't approved, Claude rejects the save with an error. To request approval for a custom header name, contact [Claude support](https://support.claude.com/en/articles/9015913-how-to-get-support).
 3. Enter the header value exactly as your server expects to receive it.
 4. Choose whether the header is **Required**. When a required header has no stored value at connection time, the connection fails. When an optional header has no value, Claude simply omits it from the request.
 5. Repeat for any additional headers your server needs (you can add up to four), then click **Add**.

 | `static_headers`        | Fixed credential (API key or bearer token) entered by an organization administrator as a request header when adding the connector                       | Beta                                                      |
 | `none`                  | No authentication (authless server)                                                                                                                     | Supported. An optional partial-auth mode is experimental. |
 
-Static bearer tokens and API keys are supported in beta through request headers (`static_headers`). An organization administrator enters the credential once when adding the connector, and Claude sends it on every request. The credential is shared by the organization rather than pasted per user. See [Authenticating with request headers](/docs/connectors/custom/remote-mcp#authenticating-with-request-headers) for what administrators see and how to document the expected header for them.
+Static bearer tokens and API keys are supported in beta through request headers (`static_headers`). An organization administrator enters the credential once when adding the connector, and Claude sends it on every request. The credential is shared by the organization rather than pasted per user. Standard header names such as `authorization` and `x-api-key` work for every connector; Anthropic reviews and approves any other header name before administrators can save the connector. See [Authenticating with request headers](/docs/connectors/custom/remote-mcp#authenticating-with-request-headers) for what administrators see and how to document the expected header for them.
 
 Tokens or API keys passed in the connector URL (for example, `?token=`, `?apiKey=`, or `?userToken=` query parameters) are **not recommended**. A credential in a URL is a security vulnerability: URLs are routinely recorded in server logs, proxies, and browsing history, so a query-string credential is easy to leak. The MCP authorization specification explicitly [prohibits access tokens in the URI query string](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#token-requirements). Use OAuth or [request headers](/docs/connectors/custom/remote-mcp#authenticating-with-request-headers) instead.
 

 
 Steps 1 and 2 are [starting a session](#start-a-session): a message tags Claude in, and a sandbox builds for that thread. Step 3, the working loop, is [the checklist](#how-the-checklist-updates) below. Steps 4 and 5, the result and the quiet period that follows, are covered in [What survives between replies](#what-survives-between-replies).
 
-Every session runs in an ephemeral sandbox Anthropic hosts, a real working environment where it can read documents, run code, build charts, and open pull requests. Claude clones your repositories into the sandbox, edits them there, and pushes changes back to your Git host as a branch or pull request. The sandbox runs the same engine that powers Claude Code on the web, Anthropic's agent for writing and running code, which is why the results are working artifacts rather than chat.
+Every session runs in an ephemeral sandbox Anthropic hosts, a real working environment where it can read documents, run code, build charts, and open pull requests. Claude clones your GitHub repositories into the sandbox, edits them there, and pushes changes back to GitHub as a branch or pull request. The sandbox runs the same engine that powers Claude Code on the web, Anthropic's agent for writing and running code, which is why the results are working artifacts rather than chat.
 
 Two threads in the same channel are two separate sessions with separate sandboxes; sessions don't share state directly.
 

 | Self-managed                      | Your hostname under **Advanced → Allowed websites**           | [GitHub Enterprise setup](/docs/claude-tag/admins/configure-github#github-enterprise)                      |
 | Handing back changes              | Manages issues and comments on merge requests through the API | [Draft pull requests](/docs/claude-tag/users/use-cases/work-with-github) authored by the Claude GitHub App |
 
+The connection is API-only. The token authenticates GitLab API requests, not git, so Claude gets a 401 error when it tries to clone a private project or push to any project over HTTPS, even with the connection in place. To clone a repository into the session workspace, connect it through [GitHub](/docs/claude-tag/admins/configure-github) instead.
+
 The token is auto-injected on every API request to your GitLab host. The model and the sandbox are not given the key; see [how Agent Proxy works](/docs/claude-tag/concepts/agent-identity#agent-proxy).
 
 ## Related resources

 
 Connecting GitLab lets Claude read repository contents, manage issues, review and comment on merge requests, and check pipeline status from any channel under a bundle's scope, all through the GitLab API. Unlike GitHub, there is no Claude app to install in GitLab. Instead, you give Claude its own GitLab user and add that user's personal access token to an Access bundle.
 
+The connection is API-only. The token authenticates GitLab API requests, not git, so Claude gets a 401 error when it tries to clone a private project or push to any project over HTTPS, even with the connection in place. To clone a repository into the session workspace, connect it through [GitHub](/docs/claude-tag/admins/configure-github) instead.
+
 A dedicated service account keeps Claude's GitLab activity attributed to a single identity you control. You decide which groups and projects it can reach by granting that account membership the same way you would for a person, and you can revoke or rescope it at any time without touching anyone else's access.
 
 ## Prerequisites