(Bug) Terminal tool spawns Gradle/Java processes that fail loopback handshake — Unable to establish loopback connection

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

After a Claude Code Desktop update, shell commands run through the terminal tool that spawn Gradle/Java processes (specifically flutter run targeting an Android emulator) fail immediately with:

This is Gradle's client-daemon local socket handshake failing.

What Should Happen?

flutter run (and other commands that spawn Gradle/Java processes) executed through Claude Code's terminal tool should succeed and behave identically to running the same command in a standard terminal (PowerShell/Command Prompt) on the same machine. The build should complete and launch the app on the target device/emulator without the Gradle daemon failing to establish its local loopback socket connection.

Error Messages/Logs

Got it — and this is a much more specific/valuable finding than a generic "loopback blocked" error. Here's the full raw stack trace:

Read
gradle_stacktrace.log
This narrows it down significantly — this is not a firewall/TCP-loopback block at all, despite the misleading top-level message. The real failure is three frames deep:

The JVM's Selector.open() (via WEPollSelectorImpl) implements its internal wakeup pipe using an AF_UNIX domain socket — a Windows 10/11 feature, not a TCP loopback socket. That AF_UNIX connect() syscall is the thing failing with Invalid argument, not a blocked TCP port. Let me grab the TEMP path context, since AF_UNIX sockets on Windows are backed by a socket file and are sensitive to the filesystem/path they're created on.

Checked TEMP/TMP path used in this execution environment
That TEMP path is a normal local NTFS path under the real user profile (C:\Users\Hjalmar J Lopez\AppData\Local\Temp) — not redirected, virtualized, or a network path, and it's the same one Android Studio's Kotlin daemon was using in its process command line earlier tonight. So the AF_UNIX socket file location itself isn't the obvious differentiator; something about the process's privilege/token or network-namespace context under Claude Code's terminal tool is the more likely blocker for that native connect0 call.

Full log is saved at gradle_stacktrace.log in the scratchpad if you want the raw file too. Here's the report-ready packet:

Root cause (from --stacktrace): The top-level "Unable to establish loopback connection" is misleading — it is not a blocked TCP loopback socket. The actual failure is three frames down:

wrapped by:

wrapped by the generic Gradle daemon-connector message:

What this actually means: the JVM's NIO Selector.open() uses WEPollSelectorImpl on Windows, whose internal self-wakeup pipe is backed by an AF_UNIX domain socket (a Win10/11 feature), not a TCP loopback socket. That native connect0() call is failing with Invalid argument, which is what surfaces upward as Gradle's generic "loopback connection" error. This explains why hours of AV/firewall/driver troubleshooting had no effect: TCP loopback was never the actual mechanism involved.

Confirmed environment details:

TEMP/TMP = C:\Users\Hjalmar J Lopez\AppData\Local\Temp — a normal local NTFS path, not redirected/virtualized, same one used by a successful Android Studio-launched JVM in the same session
JDK: OpenJDK 21.0.10 (Android Studio bundled JBR), Gradle 8.13
Identical command succeeds in a normal PowerShell window and via Android Studio; fails 100% of the time via Claude Code's terminal tool, with and without dangerouslyDisableSandbox

Steps to Reproduce

100% reproducible running flutter run -d <emulator-id> through Claude Code's Bash/terminal tool
Fails identically with dangerouslyDisableSandbox: true, with a fully cleared Gradle daemon, and with Windows Defender folder/process exclusions in place for the project, .gradle, GradleHome, and the JDK
The exact same command, same machine, same project, same running emulator, succeeds every time when run manually in a normal PowerShell window, or via Android Studio's own Run button
Failure is fast and consistent (~4-7s), consistent with a new process's loopback socket being rejected rather than a timeout

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

4.6

Claude Code Version

1.22209.0.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Impact: Cost several hours of misdirected debugging (uninstalling antivirus software, resetting the Windows network stack, testing multiple JDK versions) before isolating that the terminal tool's execution path — not the OS/environment — was the actual variable.

Environment: Windows 11 Pro (10.0.26200), Flutter/Gradle 8.13, JDK 21 (Android Studio bundled JBR)

Claude Code Desktop (built-in terminal)