# Claude Code Git URL Privacy: What Gets Sent and How to Limit It

Understand Claude Code’s Git URL reporting, feature flags, gateway risks, and privacy settings, with practical steps to audit your configuration.

Canonical URL: https://aiidelist.com/blog/claude-code-git-url-privacy-telemetry

Language: en

Published: 2026-10-23

Updated: 2026-10-23

## Key Takeaways

- **Published reverse engineering identifies a conditional Git repository reporting mechanism in Claude Code 2.1.303 and 2.1.306.** The `jy` field inside `x-claude-code-wiggly-dove` can contain a readable repository identifier.
- **The evidence does not establish universal collection.** The analyzed implementation depends on a feature flag and request-target checks.
- **The claim that collection cannot be disabled is too broad.** Official documentation provides controls for telemetry and feature-flag fetching.
- **A custom API gateway does not automatically disable Anthropic operational telemetry.** Model requests and background services must be assessed separately.
- **Disabling telemetry does not make cloud inference local.** Prompts and file contents included in model requests still reach the configured inference service.

**Updated October 23, 2026.** The findings below distinguish version-specific community research, documented settings, and privacy implications inferred from those mechanisms.

## What Is the Claude Code Git URL Controversy?

The controversy concerns whether Claude Code can attach a project's Git repository identity to outbound requests, potentially revealing an organization or private project name.

A [reverse-engineering analysis of Claude Code 2.1.303](https://blog.xinrao.moe/article/3fe2c64d-9f79-80a5-b5cd-f429c899c952) identifies the custom request header `x-claude-code-wiggly-dove`. Its `jy` member can carry a normalized repository identifier. A [separate analysis covering CLI 2.1.306](https://blog.ixixix.cn/posts/claude-client-reverse-engineering/) describes the same mechanism. These are community findings, not an Anthropic disclosure of the field's server-side purpose. 

The distinction between capability and observed collection matters:

| Claim | Evidence-based assessment |
| --- | --- |
| The analyzed clients contain repository-identification logic | Supported by published reverse engineering |
| A readable repository identifier can enter an API request header | Supported for the analyzed implementation |
| Every user of every 2.1.30x release sends this identifier | Not established |
| The mechanism uploads an entire repository | Not established by the header findings |
| No privacy settings can affect it | Inconsistent with documented feature-flag controls |
| Anthropic uses this field to identify security research or ban accounts | Not established by the available client-side evidence |

**The defensible finding is conditional repository metadata transmission.** Describing it as a proven compromise of every private repository goes beyond the evidence.

## How the Git Repository Identifier Is Constructed

The 2.1.306 report describes a code path that reads the repository's `origin` configuration, including `pushurl` or `url`, and constructs a shortened repository identifier. Query parameters are removed, but recognizable host, organization, and repository components can remain. 

For illustration, a configured remote might look like this:

```text
https://github.com/example-org/private-project.git
```

The relevant header member could resemble:

```text
jy="github.com/example-org/private-project"
```

These are fictional examples, not captured requests. The second example shows only the repository member, not a complete header.

**Normalization is not anonymization.** Removing a protocol prefix, query string, or `.git` suffix can leave enough information to identify the project.

The 2.1.303 analysis also maps contextual members:

| Member | Reported meaning |
| --- | --- |
| `jy` | Normalized repository identifier |
| `ob` | Client version |
| `sk` | Client entry point |
| `wl` | Request category |
| `tt` | Automatic permission-policy state |
| `bf` | Container or sandbox category |
| `vd` | Host environment category |
| `zx` | Network egress constraints |

Presence depends on construction conditions, and these internal names should not be treated as a stable public API. 

A readable HTTP header also does not imply an unencrypted internet connection. HTTPS can protect transport while leaving the header visible to the receiving service and any authorized intermediary terminating TLS.

## When Does Claude Code Send the Header?

The analyzed implementation uses the feature flag `tengu_wiggly_dove`, with a fallback value of `false`. The 2.1.303 report also identifies provider and configured-target checks. Those checks describe client configuration logic; they do not independently prove the identity of every eventual network destination. 

Several questions therefore need separate answers:

1. Does the installed build contain the implementation?
2. Is the relevant feature enabled for that session?
3. Does the configured request path qualify?
4. Can the client derive a repository identifier?
5. Does an observed outbound request actually contain it?

An installed version number answers only the first question imperfectly. It does not establish what happened in a particular session.

Likewise, a fallback of `false` is not proof that the flag is disabled for every account. Remote configuration can select different behavior without requiring another local installation.

**Version-specific findings should not be extended automatically to earlier builds, later releases, or different client surfaces.**

## Why Repository Metadata Can Be Sensitive

The privacy significance depends on what the repository name reveals and who receives it.

A public repository identifier may reveal little new information. A private identifier could expose an unreleased product, customer relationship, acquisition project, or internal research initiative.

There is also a potential correlation risk: requests carrying the same repository identifier could be grouped as activity involving the same project. That is a technical possibility, not evidence that a provider actually performs such grouping or uses it for enforcement.

| Repository context | Potential sensitivity |
| --- | --- |
| Public open-source project | Association between a user or session and an already public project |
| Unreleased commercial product | Product name and organizational ownership |
| Client-specific development | A confidential business relationship |
| Internal security research | Research topic or engagement identity |
| Private infrastructure repository | Internal naming conventions or system roles |

A practical review should ask **whether the repository's name itself is confidential**, alongside the usual review of source code and credentials.

## API Gateways, Telemetry, and OpenTelemetry Are Different Paths

Setting `ANTHROPIC_BASE_URL` changes the model API endpoint. It should not be interpreted as a switch that redirects or disables every background connection.

Anthropic's [managed settings documentation](https://code.claude.com/docs/en/managed-settings) states that operational telemetry is enabled by default for Anthropic API sessions, including sessions using an LLM gateway or custom base URL. It documents deploying `DISABLE_TELEMETRY` to turn that collection off. 

Three paths deserve separate inspection:

| Path | What to inspect | Why it matters |
| --- | --- | --- |
| Model API traffic | Destination, request headers, and request body | Carries inference input and potentially additional metadata |
| Operational telemetry and feature evaluation | Background endpoints and payloads | Can operate independently of the model gateway |
| Organization-configured OpenTelemetry | Exporters, collector destinations, and enabled attributes | Follows a separate monitoring configuration |

The [B1anYu telemetry audit](https://github.com/B1anYu/claude-telemetry-audit), which examined Claude Code CLI 2.1.283, reports an `apiBaseUrlHost` field in feature-evaluation traffic. It identifies the configured gateway hostname alongside other client attributes. Because that audit covers an earlier build, it supports a separate telemetry concern rather than proving the precise behavior of every 2.1.30x release. 

For a model request routed through a gateway, distinguish two observations:

- **Gateway ingress:** what Claude Code sends to the gateway.
- **Gateway egress:** what the gateway forwards to its upstream service.

An ingress capture alone cannot establish that a particular header reached Anthropic. The gateway might remove it, transform the request, or use another upstream.

## Repository Attributes in OpenTelemetry Are a Separate Feature

Claude Code also provides a documented repository-tagging option for organization-managed monitoring:

```bash
export OTEL_METRICS_INCLUDE_REPOSITORY=true
```

According to the [monitoring documentation](https://code.claude.com/docs/en/monitoring-usage), this option defaults to `false`. When enabled in a configured telemetry deployment, it can add attributes such as `vcs.repository.url.full`, `vcs.owner.name`, and `vcs.repository.name`.

The documentation states that these repository attributes go to the user's exporters and that Anthropic telemetry drops `vcs.*` keys. 

That statement concerns the documented OpenTelemetry attributes. It should not be generalized into a claim that no other request path can carry repository information.

Conversely, the existence of the separate `jy` mechanism does not establish that the documented OpenTelemetry configuration behaves differently from its specification.

## How to Disable Telemetry and Feature-Flag Fetching

The appropriate settings depend on whether the goal is to stop operational metrics, stop remote flag evaluation, or reduce nonessential traffic more broadly.

The [official environment-variable reference](https://code.claude.com/docs/en/env-vars) documents these controls:

| Variable | Documented effect |
| --- | --- |
| `DISABLE_TELEMETRY=1` | Disables telemetry and feature-flag fetching |
| `DISABLE_GROWTHBOOK=1` | Disables feature-flag fetching and uses code defaults; does not independently disable telemetry event logging |
| `DISABLE_ERROR_REPORTING=1` | Disables error reporting |
| `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1` | Broadly disables nonessential traffic, including telemetry, error reporting, automatic updates, and feature-flag fetching |

For the analyzed default-false repository-header flag, preventing remote activation is relevant. **This is not a permanent guarantee about future builds whose code defaults could change.** 

**macOS, Linux, and WSL**

A broad configuration can be applied before launching the client:

```bash
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
export DISABLE_GROWTHBOOK=1
export DISABLE_TELEMETRY=1
export DISABLE_ERROR_REPORTING=1

claude
```

**Windows PowerShell**

```powershell
$env:CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC = "1"
$env:DISABLE_GROWTHBOOK = "1"
$env:DISABLE_TELEMETRY = "1"
$env:DISABLE_ERROR_REPORTING = "1"

claude
```

The four variables overlap. This explicit configuration expresses a broad privacy preference; it does not mean four independent switches are required to disable one field.

A narrower starting point is `DISABLE_TELEMETRY=1`, which also stops feature-flag fetching. Organizations should choose the scope deliberately and verify the installed version's behavior.

## Make the Configuration Persistent

For local Claude Code sessions, merge the following into `~/.claude/settings.json`:

```json
{
  "env": {
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
    "DISABLE_GROWTHBOOK": "1",
    "DISABLE_TELEMETRY": "1",
    "DISABLE_ERROR_REPORTING": "1"
  }
}
```

**Preserve existing settings.** Add these entries to an existing `env` object rather than replacing authentication, model, permissions, or other configuration.

Anthropic's [settings documentation](https://code.claude.com/docs/en/settings) distinguishes user, project, local-project, and managed settings. Project and organizational settings can affect the final effective configuration. Cloud sessions run on another machine and do not inherit every local setting. 

After making changes:

1. Close existing Claude Code sessions.
2. Restart the actual launcher used for development.
3. Check for conflicting project or managed settings.
4. Verify outbound behavior from that launch path.

For teams, deploy the intended values through managed settings so enforcement does not depend on individual shell profiles. Anthropic notes that disabling telemetry also removes the usage data that feeds its organization analytics dashboard for affected developers. 

## What These Settings Affect—and What They Leave Active

The broad nonessential-traffic switch disables automatic updates and can make remotely gated features unavailable. Disabling GrowthBook also affects features requiring fetched flags, including Remote Control. Maintain an explicit update process if automatic updating is disabled.

There is a configuration trap: the current documentation says `DISABLE_TELEMETRY`, `DISABLE_ERROR_REPORTING`, and `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC` treat any nonempty value as enabled. Setting them to `0` or `false` does not reverse the opt-out; unset them when appropriate. 

**Normal inference remains a separate data flow.** The model needs the prompts and context sent to it. Anthropic's [data usage documentation](https://code.claude.com/docs/en/data-usage) treats operational telemetry, error reports, and submitted feedback as distinct mechanisms. A telemetry opt-out is not an instruction to remove sensitive material from inference requests. 

Consequently, a complete privacy review must still consider which files the agent can read, what tool output enters the conversation, and which service receives that conversation.

## How to Audit Whether Your Installation Sends Git Metadata

A useful audit records evidence at three levels: installed build, effective configuration, and actual requests.

**1. Record the client version**

```bash
claude --version
```

Keep the version, operating system, installation method, provider mode, and launch method with the test results. Repeat relevant checks after upgrades.

**2. Inspect repository configuration locally**

```bash
git remote -v
git remote get-url --all origin
git remote get-url --push --all origin
```

The [Git remote documentation](https://git-scm.com/docs/git-remote) explains the URL inspection options, including push URLs. These commands help identify potentially sensitive repository names; they do not demonstrate that Claude Code transmitted them. Keep their output private if it contains confidential names or embedded credentials. 

**3. Use a disposable test repository**

Create an empty test directory with a clearly fictional remote identifier. Use a unique marker so it can be found in captured traffic. Avoid real customer code and production credentials in a local mock-receiver experiment.

**4. Observe the relevant requests**

A proposed test matrix is:

| Test | What it can establish |
| --- | --- |
| Baseline session without privacy overrides | Whether the sampled configuration emits the header or repository member |
| Fresh session with `DISABLE_TELEMETRY=1` | Whether behavior changes after the telemetry and flag-fetching opt-out |
| Fresh session with `DISABLE_GROWTHBOOK=1` | Whether disabling remote flag evaluation changes the result |
| Fresh session with the broad configuration | Whether optional background connections remain |
| Gateway ingress and egress captures | Whether a received field is forwarded upstream |

These are suggested experiments, not reported measurements.

**5. Account for two common false negatives**

First, a local mock endpoint may change the request-target classification. If the header requires a qualifying first-party target, changing the base URL can prevent the behavior being investigated. An empty local capture then establishes only what happened under that altered configuration.

Second, a baseline that never emits the header cannot prove that an opt-out removed it. The feature may already be inactive. A strong result includes a positive baseline, a controlled configuration change, and a comparable fresh-session capture—or clearly states that such a comparison was unavailable.

**6. Capture at a layer that can inspect headers**

Ordinary encrypted packet captures do not expose HTTPS headers. Use an authorized inspection proxy or logs at an endpoint under your control. Protect captured authorization values and conversation content.

Anthropic's [network configuration documentation](https://code.claude.com/docs/en/network-config) describes supported proxy and certificate configuration. Network observations should include background requests as well as the main inference connection. 

## Common Mistakes That Produce False Confidence

- **Treating a custom base URL as a complete privacy boundary.** Background telemetry and feature evaluation require separate inspection.
- **Assuming a private repository hides its name.** Repository access restrictions do not prevent a client from transmitting a locally stored remote identifier.
- **Removing a remote and declaring the problem solved.** That can disrupt Git workflows while leaving repository details elsewhere in prompts, files, or tool output.
- **Checking only the request body.** A metadata review must also cover headers.
- **Checking only one quiet session.** Account state, feature configuration, provider selection, and launch method can change the observed result.
- **Using today's configuration to infer historical behavior.** Current settings cannot prove what an older session sent.
- **Rolling back without a verified safe boundary.** An older version should not be called privacy-safe without evidence covering that build, and rollback can introduce unrelated maintenance risks.

## Frequently Asked Questions

**Does this prove Claude Code uploads an entire private Git repository?**

No. A repository identifier and repository contents are different data. The header findings establish a metadata mechanism. File contents can separately enter inference requests when included as context.

**Can a repository identifier expose a project without granting repository access?**

Yes. A meaningful organization or project name may itself be confidential. Knowing that name does not automatically provide permission to clone the repository.

**Does Anthropic definitely receive the identifier through every third-party gateway?**

No. That conclusion requires evidence about client emission, gateway forwarding, and upstream destination. Each is a separate step.

**Do the reports prove account bans are based on Git URLs?**

No. Client-side construction logic does not reveal server-side enforcement decisions. Project correlation is a plausible privacy implication, not a demonstrated explanation for account action.

**Can an audit prove nothing was sent in the past?**

Only historical evidence can address historical transmission. Relevant records may include retained endpoint logs or contemporaneous captures. A clean test today has a narrower meaning.

## Conclusion

The Claude Code Git URL controversy raises a legitimate concern about repository metadata. Published analyses identify a conditional mechanism capable of attaching readable project identifiers to API requests. They do not establish universal deployment, unavoidable collection, or a specific enforcement purpose.

**Review the installed version, apply the appropriate privacy settings, restart the actual development workflow, and verify its outbound requests.** For teams working on confidential projects, make that verification part of upgrade review and assess model traffic, operational telemetry, and organization-managed monitoring separately.