Build failures regarding sentry-cli7059257849644749494.exe on macOS

[G00fY2]

Gradle Version

8.5

AGP Version

8.2.0

Code Minifier/Optimizer

None

Version

4.0.0

Sentry SDK Version

7.1.0

Steps to Reproduce

Apply sentry gradle plugin Use gradles default build and configuration cache Try to build project multiple times after switching branches

Expected Result

App should build

Actual Result

I get very strange error messages about sentry-cli .exe files on my macOS machine.

For me this looks like some kind of caching issue of the Gradle project. Deleting the .gradle folder in the project root folder seems to fix the issue.

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred starting process 'command '/var/folders/xy/wq3rx80x6ydcx3vvy9dnt0t40000gn/T/.sentry-cli7059257849644749494.exe''
> Could not start '/var/folders/xy/wq3rx80x6ydcx3vvy9dnt0t40000gn/T/.sentry-cli7059257849644749494.exe'

* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

* Exception is:
org.gradle.process.internal.ExecException: A problem occurred starting process 'command '/var/folders/xy/wq3rx80x6ydcx3vvy9dnt0t40000gn/T/.sentry-cli7059257849644749494.exe''
	at org.gradle.process.internal.DefaultExecHandle.execExceptionFor(DefaultExecHandle.java:241)
	at org.gradle.process.internal.DefaultExecHandle.setEndStateInfo(DefaultExecHandle.java:218)
	at org.gradle.process.internal.DefaultExecHandle.failed(DefaultExecHandle.java:386)
	at org.gradle.process.internal.ExecHandleRunner.lambda$run$3(ExecHandleRunner.java:102)
	at org.gradle.internal.operations.CurrentBuildOperationRef.with(CurrentBuildOperationRef.java:80)
	at org.gradle.process.internal.ExecHandleRunner.run(ExecHandleRunner.java:101)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47)
Caused by: net.rubygrapefruit.platform.NativeException: Could not start '/var/folders/xy/wq3rx80x6ydcx3vvy9dnt0t40000gn/T/.sentry-cli7059257849644749494.exe'
	at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:27)
	at net.rubygrapefruit.platform.internal.WrapperProcessLauncher.start(WrapperProcessLauncher.java:36)
	at org.gradle.process.internal.ExecHandleRunner.startProcess(ExecHandleRunner.java:122)
	at org.gradle.process.internal.ExecHandleRunner.lambda$run$0(ExecHandleRunner.java:80)
	at org.gradle.internal.operations.CurrentBuildOperationRef.with(CurrentBuildOperationRef.java:80)
	at org.gradle.process.internal.ExecHandleRunner.run(ExecHandleRunner.java:79)
	... 2 more
Caused by: java.io.IOException: Cannot run program "/var/folders/xy/wq3rx80x6ydcx3vvy9dnt0t40000gn/T/.sentry-cli7059257849644749494.exe" (in directory "/Users/twirth/AndroidStudioProjects/android-client"): error=2, No such file or directory
	at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:25)
	... 7 more
Caused by: java.io.IOException: error=2, No such file or directory
	... 8 more


BUILD FAILED in 551ms

[romtsn]

@G00fY2 would you be able set the debug flag to true and build your project with --info and post the output here (maybe as an attachment) when you encounter the error?

sentry {
  debug = true
}

[G00fY2]

Will try, but probably not until next year. 👍

PS: Merry Christmas and a Happy New Year.

[romtsn]

Will try, but probably not until next year. 👍

PS: Merry Christmas and a Happy New Year.

thanks, no rush! We'll try to reproduce ourselves though, but happy holidays in the meantime!

[msfjarvis]

I also face this problem infrequently, I believe it's an issue with configuration caching.

My hunch is that the CLI executable path that's computed by SentryCliProvider#loadCliResourcesToTemp ends up getting persisted as part of SentryUploadProguardMappingsTask's inputs. When the cache is re-used after any system event that clears out the user's temporary directory, it tries to execute a non-existent binary based on the cached input path.

Re-running with --no-configuration-cache resolves the problem since it causes a new path to be computed. After the run has completed and the new configuration cache has been stored, you can reproduce the problem by manually deleting the /tmp/.sentry-cli$bunch_of_numbers.exe file (path dependent on your choice of OS) and running the build/install task again without specifying --no-configuration-cache.

[kahest]

Thank you @msfjarvis for the details and the findings, your reasoning makes sense IMO - we'll investigate

[romtsn]

Thanks for the details @msfjarvis, I was able to reproduce it locally. We'll try to provide a fix soon!

[Shabinder]

+1

[kahest]

A fix for this was shipped with release 4.2.0 today.

[purposebakery]

I'm seeing this again in 5.10.0 (AGP: 8.12.0). Macbook M2 Max. MacOS: 15.6.1.

[amirhosein-sa]

Seeing this issue on Ubuntu ! sentry version: 5.12.2 AGP: 8.13

[romtsn]

hi folks who are still seeing this - can anyone provide a reproducible sample? I'd expect our tests would've failed if there was a regression, specifically this one: https://github.com/getsentry/sentry-android-gradle-plugin/blob/0ce926822756c8379e281bed8c33237a400c9582/plugin-build/src/test/kotlin/io/sentry/android/gradle/integration/SentryPluginConfigurationCacheTest.kt#L163

[sebastian-gallese-speak]

Encountered this issue after upgrading Android Studio. Sharing findings:

Environment

• OS: macOS Darwin 24.6.0 (arm64)
• Android Studio: Otter 2 Feature Drop | 2025.2.2 (upgraded from Narwhal)
• Gradle: 8.13
• AGP: 8.13.1
• Sentry Plugin: 5.12.2
• Sentry Android SDK: 8.28.0
• Configuration Cache: Enabled (org.gradle.configuration-cache=true)

What Triggered It Upgrading Android Studio from Narwhal to Otter 2025.2.2. The build worked fine before the upgrade.

Maybe issues is stale Gradle daemon after the Android Studio upgrade.

1. Configuration cache cached old sentry-cli path: The cache had a reference to sentry-cli-2.46.0.exe from a previous build
2. Temporary file was cleaned up: System cleared the temp directory between builds
3. Build failed: Gradle tried to execute the cached (non-existent) path
4. Fresh extraction worked: Running with --no-configuration-cache forced the plugin to extract a fresh binary (sentry-cli-2.51.1.exe), which worked fine

Solution That Worked ./gradlew --stop # Kill stale Gradle daemon ./gradlew build # Fresh daemon works with configuration cache enabled

After restarting the daemon, builds work normally with configuration cache enabled. There was no need to disable config cache or modify

[romtsn]

@sebastian-gallese-speak thanks for the details! this looks like a plausible case to reproduce, I will have a look.

[linear[bot]]

GRADLE-70