When a project already has sentry.gradle configured and disableAutoUpload is false (or toggled back from true to false), the function returns early at line 51 without removing a pre-existing shouldSentryAutoUploadGeneral = { -> return false } override, permanently disabling uploads even after the option is cleared.

Also found at:

• packages/core/plugin/src/withSentryIOS.ts:44

When disableAutoUpload is changed from true back to false and prebuild is re-run, modifyExistingXcodeBuildScript and addDisableAutoUploadToExistingScript never remove the previously injected export SENTRY_DISABLE_AUTO_UPLOAD=true, so source map uploads remain disabled despite the user's intent.

Also found at:

• packages/core/plugin/src/withSentry.ts:72-78

In withSentryIOS.ts modifyExistingXcodeBuildScript, when sentry-xcode.sh is already present (re-prebuild) and disableAutoUpload is false, the function only emits a warning and returns without removing a previously injected export SENTRY_DISABLE_AUTO_UPLOAD=true line, leaving iOS source-map uploads permanently disabled after any prior true run.

In modifyAppBuildGradle (withSentryAndroid.ts), when build.gradle already contains sentry.gradle, the only mutation branch adds project.ext.shouldSentryAutoUploadGeneral = { -> return false } when disableAutoUpload is true. There is no symmetric branch to strip the override when the user later sets disableAutoUpload: false and re-runs expo prebuild without --clean, so the upload remains silently disabled. The iOS counterpart has the same asymmetry: addDisableAutoUploadToExistingScript adds export SENTRY_DISABLE_AUTO_UPLOAD=true to existing build phases when true, but neither modifyExistingXcodeBuildScript nor the Upload Debug Symbols to Sentry branch in withSentryIOS removes a previously-injected export when disableAutoUpload is false. Add removal branches in both files (or document that prebuild --clean is required when toggling the flag off).

Also found at:

• packages/core/test/expo-plugin/modifyXcodeProject.test.ts:148-153