Java and .NET runtimes fail to execute inside AWF chroot mode (v0.13.14)

[Mossaka]

Summary

Java and .NET runtimes are completely non-functional inside the AWF agent container in chroot mode. All 20 repos tested (10 Java, 10 .NET) failed with 0 successful builds and 0 tests run. This was discovered during a large-scale build/test experiment across 98 OSS repositories spanning 10 programming languages.

Environment

• gh-aw: v0.43.2
• AWF: v0.13.14
• Runner: ubuntu-latest (GitHub Actions)
• Chroot mode: enabled (--enable-chroot)

.NET Failure

All 10 .NET repos failed identically. The dotnet CLI refuses to execute because it detects a process name mismatch:

Error: cannot execute dotnet when renamed to bash.
exit code: 132

The .NET CLR validates that its hosting process name matches "dotnet". Inside the AWF chroot execution chain (chroot → bash → capsh → bash → exec), the process name resolves to "bash" instead of "dotnet", triggering this hard security check.

Repos tested: BenchmarkDotNet, Bogus, Dapper, FluentValidation, Humanizer, Newtonsoft.Json, Polly, moq4, serilog, xunit

The Copilot agent attempted multiple workarounds including direct execution, wrapper scripts, Python subprocess, C wrappers, symlinks, and setsid — none could bypass the .NET SDK's process name validation.

Java Failure

All 10 Java repos failed identically. The Java binary outputs bash version information instead of executing Java commands. Maven and Gradle builds fail because the JVM cannot properly initialize.

Repos tested: caffeine, gson, guava, jackson-databind, mapstruct, mockito, mybatis-3, okhttp, resilience4j, retrofit

The root cause appears to be the same /proc/self/exe resolution issue — the JVM reads /proc/self/exe and finds /bin/bash instead of the Java binary, causing it to behave as a shell rather than a JVM.

Context

This was part of a build/test experiment across 10 languages (98 repos total). For comparison:

• Go: 8/10 repos built and tested successfully
• Python: 8/10 repos built successfully
• Rust: 3/10 fully passed (others hit separate linker/toolchain issues)
• JavaScript: 9/10 pipelines green
• Java: 0/10 — completely broken
• .NET: 0/10 — completely broken

The procfs mounting fix introduced in v0.13.13 (container-scoped mount -t proc at /host/proc) does not resolve these failures in v0.13.14.

Reproduction

1. Fork any Java or .NET repo (e.g., google/gson or dotnet/BenchmarkDotNet)
2. Add an agentic workflow with engine: copilot and network.allowed: [defaults, java] or [defaults, dotnet]
3. Compile with gh aw compile
4. Trigger the workflow
5. Observe the agent fails to execute java, mvn, gradle, or dotnet commands inside the AWF container

[github-actions]

👋 Hello! This issue appears to be a duplicate of an existing issue:

#518 - chroot mode: binary execution intercepted by bash causing Java, Rust, and Bun failures
#518

Why these issues are related:

Both issues describe the exact same root cause: In chroot mode, binary execution is being intercepted by bash, causing /proc/self/exe to resolve to /bin/bash instead of the actual runtime binary.

Common symptoms:

• Java: Returns bash help/version output instead of executing Java commands (both issues report this)
• .NET: "cannot execute dotnet when renamed to bash" error (your issue Java and .NET runtimes fail to execute inside AWF chroot mode (v0.13.14) #711)
• Rust: lld-wrapper sees "bash" instead of expected executable (issue chroot mode: binary execution intercepted by bash causing Java, Rust, and Bun failures #518)

Key evidence:

• Issue chroot mode: binary execution intercepted by bash causing Java, Rust, and Bun failures #518 (opened Feb 4): Reports Java commands return "bash help instead of executing"
• Issue Java and .NET runtimes fail to execute inside AWF chroot mode (v0.13.14) #711 (opened Feb 12): Reports Java outputs "bash version information" and .NET detects process name as "bash"
• Both issues affect only chroot mode (v0.13.14 for Java and .NET runtimes fail to execute inside AWF chroot mode (v0.13.14) #711, similar version for chroot mode: binary execution intercepted by bash causing Java, Rust, and Bun failures #518)
• Both report 0/10 successful builds for Java repos

Issue #518 has 53 comments with extensive investigation and attempted fixes. The community has been actively working on this problem for over a week.

Recommendation

Please review issue #518 and its discussion thread. If your issue provides additional data or insights not covered there, consider adding them as a comment to #518 to consolidate the investigation. Otherwise, you may want to close this as a duplicate.

This is an automated message from the issue duplication detector.

AI generated by Issue Duplication Detector

[Mossaka]

Verified Fixed in AWF v0.19.1 ✅

The AWF Build/Test Experiment v3 (Feb 17, 2026) confirms this issue is fully resolved:

• .NET: 0/10 builds (v2) → 9/10 builds (v3). Exit code 132 / SIGILL crash eliminated.
• Java: java, javac, gradle, mvn all execute correctly. (Java still 0/10 builds but due to firewall domain issues, not binary interception — tracked in Java builds fail 0/10: Maven Central and Gradle Plugin Portal unreachable through Squid proxy #946)
• Rust: Toolchain/linker issues resolved. 6/10 (v2) → 9/10 builds (v3). Rustup proxy binaries and lld linker wrapper work correctly in chroot mode.

The chroot binary execution rewrite that fixed argv[0] / /proc/self/exe resolution is a major milestone. It unblocked 3 programming languages in one fix.

Full report: AWF Build/Test Experiment v3 (gh-aw v0.45.2, AWF v0.19.1)