Once disableAutoUpload: true is applied and then changed to false, neither the Android shouldSentryAutoUploadGeneral override nor the iOS export SENTRY_DISABLE_AUTO_UPLOAD=true injection is removed on subsequent prebuilds, so uploads remain silently disabled. Consider adding removal logic, or at minimum documenting that --clean is required when toggling this flag.

Also found at:

• packages/core/plugin/src/withSentryAndroid.ts:52
• packages/core/plugin/src/withSentryIOS.ts:70-79

Once expo prebuild is run with disableAutoUpload: true, the shouldSentryAutoUploadGeneral = { -> return false } line is permanently baked into build.gradle. Re-running prebuild with disableAutoUpload: false silently does nothing — uploads remain disabled, violating user expectations.

Also found at:

• packages/core/plugin/src/withSentryAndroid.ts:42-49
• packages/core/test/expo-plugin/modifyAppBuildGradle.test.ts:61-63
• packages/core/test/expo-plugin/modifyXcodeProject.test.ts:3

After running prebuild with disableAutoUpload: true, changing to disableAutoUpload: false and re-running prebuild silently keeps export SENTRY_DISABLE_AUTO_UPLOAD=true in both Xcode build phases, so auto-upload remains disabled.

Also found at:

• packages/core/plugin/src/withSentryIOS.ts:46-52
• packages/core/test/expo-plugin/modifyXcodeProject.test.ts:3
• packages/core/test/expo-plugin/modifyXcodeProject.test.ts:133-137

In withSentryAndroid.ts, modifyAppBuildGradle only injects project.ext.shouldSentryAutoUploadGeneral = { -> return false } — it never removes it. Switching from disableAutoUpload: true to false and re-running prebuild leaves the override in build.gradle, permanently disabling Android source-map uploads.

In modifyExistingXcodeBuildScript (withSentryIOS.ts), when the bundle phase already contains sentry-xcode.sh and disableAutoUpload=true, addDisableAutoUploadToExistingScript(script) is invoked and may actually mutate script.shellScript to inject export SENTRY_DISABLE_AUTO_UPLOAD=true. However, the subsequent warnOnce("The latest 'sentry-xcode.sh' script already exists...") runs unconditionally, telling the user nothing was done even though a real change was made. The fix is to return after the injection (or only warn when no mutation occurred).