[BUG] Maven/Gradle builds fail in Claude Code Web cloud environment - DNS resolution failure for repo.maven.apache.org

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/12752
2. https://github.com/anthropics/claude-code/issues/12087
3. https://github.com/anthropics/claude-code/issues/10307

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

The suggested duplicates don't make this issue obsolete:

• #12752 (Gradle) - Closed as duplicate, unresolved
• #12087 (.NET/NuGet) - Closed as duplicate, unresolved
• #10307 (crates.io) - Marked as "fixed" but only for Rust/crates.io specifically

There doesn't appear to be an open issue actually tracking this problem. These issues keep getting closed as duplicates of each other in a circular pattern, but the underlying issue remains unresolved for JVM tools (Maven/Gradle), .NET (NuGet), and potentially others.

The fix applied for #10307 (adding crates.io to NO_PROXY) was package-manager-specific and didn't address the broader problem: tools that don't respect HTTP_PROXY/HTTPS_PROXY environment variables cannot access their registries through the Claude Code Web proxy.

Could this issue remain open to track the Maven/Gradle case, or could you point me to the actual open issue where this is being addressed?

Agreed, this is definitely broken.

I've not tried this on Maven yet, but this may be a possible workaround. https://www.linkedin.com/pulse/fixing-maven-build-issues-claude-code-web-ccw-tarun-lalwani-8n7oc

However, a similar approach on Gradle does not work, it gets stuck on a 401 error due to plugins.gradle.org not being an allowed domain. Explicitly setting it in allowed hosts doesn't seem to work for me either.

I am having this issue with gradle builds. I have asked the agent to fix this but I get this back

Network issue: The environment has TLS certificate verification problems - curl works with -k (insecure) but Java/Gradle cannot verify the certificates. This is blocking all dependency downloads.

Workaround: Local Proxy for Maven Authentication Issues

When Maven fails to authenticate with a corporate/egress proxy (401 Unauthorized), you can work around it by running a local proxy that handles authentication transparently:

1. Create a simple Python proxy (maven-proxy.py):

#!/usr/bin/env python3
"""Local proxy that adds auth when forwarding to upstream proxy."""
import socket, threading, os, base64, select
from urllib.parse import urlparse

LOCAL_PORT = 3128
UPSTREAM = os.environ.get('https_proxy') or os.environ.get('HTTPS_PROXY')

def get_upstream():
    p = urlparse(UPSTREAM)
    return p.hostname, p.port, p.username or '', p.password or ''

def handle(client):
    try:
        req = b''
        while b'\r\n\r\n' not in req:
            req += client.recv(4096)

        target = req.split(b'\r\n')[0].split()[1].decode()
        host, port = (target.split(':') + ['443'])[:2]

        proxy_host, proxy_port, user, pwd = get_upstream()
        auth = base64.b64encode(f"{user}:{pwd}".encode()).decode()

        upstream = socket.socket()
        upstream.connect((proxy_host, proxy_port))
        upstream.send(f"CONNECT {host}:{port} HTTP/1.1\r\nProxy-Authorization: Basic {auth}\r\n\r\n".encode())

        resp = b''
        while b'\r\n\r\n' not in resp:
            resp += upstream.recv(4096)

        if b'200' in resp.split(b'\r\n')[0]:
            client.send(b'HTTP/1.1 200 Connection Established\r\n\r\n')
            for s in [client, upstream]: s.setblocking(False)
            while True:
                r, _, _ = select.select([client, upstream], [], [], 30)
                if not r: break
                for s in r:
                    data = s.recv(8192)
                    if not data: return
                    (upstream if s is client else client).sendall(data)
    except: pass
    finally: client.close()

if __name__ == '__main__':
    srv = socket.socket()
    srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    srv.bind(('127.0.0.1', LOCAL_PORT))
    srv.listen(10)
    print(f"Local proxy on 127.0.0.1:{LOCAL_PORT}")
    while True:
        c, _ = srv.accept()
        threading.Thread(target=handle, args=(c,), daemon=True).start()

2. Run the proxy:

python3 maven-proxy.py &

3. Configure Maven (~/.m2/settings.xml):

<settings>
  <proxies>
    <proxy>
      <id>local</id>
      <active>true</active>
      <protocol>https</protocol>
      <host>127.0.0.1</host>
      <port>3128</port>
    </proxy>
  </proxies>
</settings>

Why this works: Maven connects to localhost without auth, and the local proxy injects the Proxy-Authorization header when forwarding to the upstream proxy. This bypasses Maven's proxy auth implementation issues with complex credentials (like JWT tokens).

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Still ocurring

It is a bit unexpected that you need to start all Slack messages with ”@Claude apply the workaround from https://github.com/anthropics/claude-code/issues/13372 and then …”

Will this be fixed eventually?

https://github.com/vaadin/flow/commit/b51d860caa3d74ec938899d57e6ba8991ee61708 is a much simpler workaround without python or custom proxies. Unfortunately it seems that the SessionStart hook is not executed automatically so you still need to refer to running .claude/hooks/setup-jvm-proxy.sh

Is this fixed?

We tried to move to CCW, but it looks like basic build things don't work there.

Our simple Maven builds in CCW fail with proxy/DNS issues.

Since this issue has been open for months, it means this is not a reliable workflow for us.

Maybe we are misusing CCW, and it is only for some documentation updates and research sessions, and we need to use GitHub workflows or something else.

Can someone advise on the right workflow instead of Maven builds in CCW?

Has this been fixed? I no longer see the same issue