Argocd helm library does not seem to provide an User-Agent when downloading charts

[kafeinnet]

Checklist:

• I've searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq.
• I've included steps to reproduce the bug.
• I've pasted the output of argocd version.

Describe the bug

When installing cfssl-issuers from wikimedia helm repo, this error is firing:

{"level":"fatal","msg":"rpc error: code = FailedPrecondition desc = error resolving repo revision: rpc error: code = Unknown desc = failed to list refs: authorization failed: Please set a user-agent and respect our robot policy https://w.wiki/4wJS. See also https://phabricator.wikimedia.org/T400119.\n","time":"2025-12-01T11:19:57+01:00"}

It seems that argocd helm library does not provide a User-Agent when pulling helm charts.

To Reproduce

Define an application like this:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cfssl-issuer
  namespace: argocd
spec:
  destination:
    name: in-cluster
    namespace: argocd
  project: default
  source:
    helm:
      valuesObject:
    path: cfssl-issuer
    repoURL: https://helm-charts.wikimedia.org/stable/
    targetRevision: 0.4.4

And sync the application.

Expected behavior

The helm chart is deployed (or at least downloaded) without error.

Version

argocd: v3.2.1+unknown
  BuildDate: 2025-11-30T14:07:55Z
  GitCommit: 
  GitTreeState: 
  GitTag: 3.2.1
  GoVersion: go1.25.4 X:nodwarf5
  Compiler: gc
  Platform: linux/amd64
argocd-server: v3.2.1+unknown
  BuildDate: 2025-11-30T14:07:55Z
  GitTag: 3.2.1
  GoVersion: go1.25.4 X:nodwarf5
  Compiler: gc
  Platform: linux/amd64
  Kustomize Version: could not get kustomize version: exec: "kustomize": executable file not found in $PATH
  Helm Version: v3.19.2+g8766e71
  Jsonnet Version: v0.21.0

Logs

❯ argocd app sync cfssl-issuer 
{"level":"fatal","msg":"rpc error: code = FailedPrecondition desc = error resolving repo revision: rpc error: code = Unknown desc = failed to list refs: authorization failed: Please set a user-agent and respect our robot policy https://w.wiki/4wJS. See also https://phabricator.wikimedia.org/T400119.\n","time":"2025-12-01T11:19:57+01:00"}

[dudinea]

Hi @kafeinnet! Thank you for reporting this. Unfortunately I do not believe that we can do something with this error.

The site administrators (see the links from the error message) say that they try to limit site abuse by automatic agents by blocking generic User-Agent headers (like those of go-httpclient and HTTP client libraries) and require either (if I understood them correctly):

• send user agent string containing contact information
• authenticate your requests using an on-wiki account when you are making API requests

I do not believe that we can implement the first option: ArgoCD uses the helm command to fetch charts from helm repositories and currently, AFAIK, there is no way to make helm change the user-agent string it sends in its requests. If there were such an ability in Helm, we cloud use it to specify User Agent by providing extra arguments or an extra env. variable when invoking Helm

On the other hand, it looks that you can try the second option by configuring authenticated access to that helm repo.

If you do not mind, I change the classification from bug to enhancement.

[yugannkt]

Hi @dudinea

Looking at the code, Argo CD actually uses its own native Go HTTP client in client.go to fetch the repository index file (index.yaml) from Helm repositories. The loadRepoIndex() function makes direct HTTP GET requests using Go's net/http package, rather than calling the helm CLI command.

The issue is that these HTTP requests are currently sent without a User-Agent header, which is what's causing Wikimedia's server to reject them.

Since Argo CD has direct control over these HTTP requests in its own codebase, we could add the User-Agent header to comply with repository policies like Wikimedia's. This would be a straightforward change in client.go without requiring any modifications to Helm itself.

The same approach would work for GetTags() with OCI registries, where we'd need to ensure the oras-go library's HTTP requests also include the User-Agent header.

I'd be happy to prepare a PR with this fix and appropriate tests if you think this approach makes sense. Let me know your thoughts!

[dudinea]

Hi @yugannkt! Thanks for your proposal!

Please feel free to start working on it, in my opinion it is a good idea to be able to modify user agent.

I still doubt that it will solve the original issue with this concrete repository because helm seems to use the default user-agent, so if the site owners really block default user-agent headers (as they state on the site), than probably it will block the actual fetch that is still done by helm.

[kafeinnet]

Oh, I forgot to say it but an helm install of the same chart using the helm CLI works OK. I'm having this problem only by using argocd to deploy those charts.

Anyway, thanks @yugannkt for taking care of it.

[blakepettersson]

I guess it makes sense for Helm sources to add the same user agent as it normally uses

[yugannkt]

Hy @blakepettersson

I'm working on a PR that adds User-Agent support. Currently using argocd-repo-server/<version> (<platform>) format (e.g., argocd-repo-server/v3.2.1 (linux/amd64)) which identifies the actual client making requests and includes platform info for debugging.

Happy to adjust to match Helm's simpler Helm/ format if you prefer consistency over traceability. Either way will fix the Wikimedia issue.

Thoughts @blakepettersson @dudinea?