Skip to content

Expo plugin: "Upload Debug Symbols to Sentry" resolves its script with node before loading .xcode.env, so Xcode launched from the Dock skips the upload silently (7.x) or fails the build (8.x) #6859

Closed

Description

@MoogyG

What React Native libraries do you use?

Expo (mobile only), Expo Router, Hermes, RN New Architecture

Are you using sentry.io or on-premise?

sentry.io (SaS)

Are you using any other error monitoring solution alongside Sentry?

No

@sentry/react-native SDK Version

7.11.0 (the issue is still on main, 8.30.0)

How does your development environment look like?

  • macOS 26.6.2, Xcode 27.0 (first observed on Xcode 26.6)
  • Expo SDK 57.0.27, react-native 0.86.3
  • Node 24 installed with nvm, so not on launchd's default PATH
  • ios/.xcode.env.local sets NODE_BINARY (written by expo prebuild)

Sentry.init()

Not relevant: this is a build-time issue in the @sentry/react-native/expo config plugin.

Sentry.init({ dsn: '…' });

Steps to Reproduce

  1. Expo app with the @sentry/react-native/expo plugin, npx expo prebuild.
  2. Node is installed through nvm (or Homebrew under /opt/homebrew/bin), i.e. not in /usr/bin:/bin:/usr/sbin:/sbin.
  3. Open the workspace in Xcode from the Dock or Finder, so Xcode inherits launchd's PATH, and build Release. The same thing can be reproduced from a terminal:
env -i HOME="$HOME" USER="$USER" PATH=/usr/bin:/bin:/usr/sbin:/sbin \
  xcodebuild -workspace ios/<App>.xcworkspace -scheme <App> \
  -configuration Release -sdk iphonesimulator \
  -destination 'generic/platform=iOS Simulator' build

Expected Result

The "Upload Debug Symbols to Sentry" phase finds Node the same way the "Bundle React Native code and images" phase does: it loads ios/.xcode.env and ios/.xcode.env.local through react-native/scripts/xcode/with-environment.sh, then uses $NODE_BINARY. Debug files are uploaded, or the phase fails loudly.

Actual Result

The phase script written by withSentryIOS is:

/bin/sh `${NODE_BINARY:-node} --print "require('path').dirname(require.resolve('@sentry/react-native/package.json')) + '/scripts/sentry-xcode-debug-files.sh'"`

node is only used to locate sentry-xcode-debug-files.sh, and that script is what loads .xcode.env*. At that point NODE_BINARY is not set yet, so it falls back to node, which is not on launchd's PATH:

  • 7.11.0 (unquoted substitution): the build log shows Script-….sh: line 2: node: command not found. /bin/sh then gets no argument, reads empty stdin and exits 0. The Release build succeeds and no debug files are uploaded. That one log line is the only sign, so native crashes from that build reach Sentry unsymbolicated.
  • main / 8.x (quoted since Expo plugin: iOS build phases break when the project path contains a space (unquoted command substitutions) #6583, getDebugFilesUploadScript → /bin/sh "<substitution>"): inferred from the code and checked with the bare shell command, not with a full 8.x Xcode build. /bin/sh "" fails with /bin/sh: : No such file or directory, exit 127. The build would now fail instead of silently skipping the upload:
$ env -i PATH=/usr/bin:/bin:/usr/sbin:/sbin /bin/sh -c '/bin/sh "`${NODE_BINARY:-node} --print 1`"'
/bin/sh: node: command not found
/bin/sh: : No such file or directory
$ echo $?
127

Confirmation that the environment is the only cause: running the same phase command after sourcing node_modules/react-native/scripts/xcode/with-environment.sh gives the script NODE_BINARY from .xcode.env.local, and sentry-xcode-debug-files.sh runs (SENTRY_DISABLE_AUTO_UPLOAD=true, skipping debug files upload in our setup).

Builds started from a shell whose PATH contains node (CI, npx expo run:ios) are not affected.

Possible fix: source with-environment.sh (or .xcode.env / .xcode.env.local) in the phase before resolving the script path, as React Native's bundle phase does.

Activity

  1. linear-code commented on Oct 8, 2026

    @linear-code
  2. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on Oct 8, 2026
  3. alwx commented on Oct 9, 2026

    @alwx
    Contributor

    Thanks for reporting.

    There is already a PR fixing this: #6860
    We're working on making it merged asap.

  4. self-assigned this
    on Oct 9, 2026
  5. added 3 commits that reference this issue on Oct 15, 2026
    f18d2b0
    ac1e1cf
    1646c2c
  6. github-actions commented on Oct 15, 2026

    @github-actions
    Contributor

    A PR closing this issue has just been released 🚀

    This issue was referenced by PR #6861, which was included in the 8.31.0 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions