When DevTools Stays Silent in Expo Go on Android, Suspect

I was reading through the Expo issue tracker when one report made my stomach tighten. On Android, in Expo Go, you press j to open React Native DevTools, type an expression into the Console, and nothing comes back. The Sources tab is empty too.

There's no error and no crash. The debugger is just quiet. That's exactly the kind of symptom that makes you spend an hour re-reading your own useEffect hooks for nothing.

Here is the short version up front. This looks like a problem on the Expo Go side for Android, so I sort out the environment first and read my code second. Everything below is as of October 29, 2026. As an indie developer I haven't reproduced this myself; I'm working from the public report and its comments, and I'll say so wherever it matters.

What the symptom looks like

The report describes it like this:

Typing an expression such as 1 + 2 in the Console returns nothing
The Sources tab lists no files
Some commenters say the Components and Profiler tabs stop working as well

expo/expo#46333 says it reproduces on a fresh SDK 56 project created from the default create-expo-app template. One commenter reports the same on SDK 57, and the issue was still open on October 28, 2026.

What matters is that the report doesn't depend on your code. If an empty app does this, re-reading your components won't get you anywhere.

Three checks before you blame your code

Try these in order. They go from cheapest to most informative.

Check	What to do	How to read it
1. Same steps on iOS	Open the same project in Expo Go on an iPhone or simulator, press `j`, and evaluate something in the Console	If iOS works, suspect the Android environment
2. A fresh project	Run `npx create-expo-app@latest`, open it in Expo Go on Android, and repeat	If an empty app is silent too, your code isn't involved
3. Terminal logs	See whether `console.log` output reaches the Metro terminal	If logs arrive, the app is running and only the debugger path is dead

Don't treat the third check as settled. The report is about Console evaluation and Sources, and it doesn't claim that log forwarding stops. Whether logs arrive on your setup is something to confirm yourself.

What has been reported about the cause

The report goes one level deeper. If you take a WebSocket URL from Metro's /json/list and send a Chrome DevTools Protocol message directly, Runtime.evaluate comes back with -32601 (Method not found).

So the quiet Console isn't a rendering glitch. The path between the debugger and the JS runtime appears to reject the evaluate method.

Past that point, nothing is confirmed. The issue is labeled Android, sdk-56, and sdk-57, and Expo's own triage note stops at "JS debugging in Expo Go on Android fails." As of October 29, 2026 I don't know the root cause or when a fix will land.

Carrying an unknown back home unresolved is part of troubleshooting too. While the cause is unconfirmed, I don't try to fix it; I route around it. That's the line I work by.

Routing around it: use a development build

One commenter on the same issue reported a workaround that worked: run a development build instead of Expo Go, and the debugger behaves normally. They note that only Expo Go on Android is affected.

If you have Android Studio and a device or emulator, two commands are enough.

# Add the dev client to your dependencies
npx expo install expo-dev-client
 
# Generate the native project and install it on a device or emulator
npx expo run:android

When the build finishes, start Metro as usual and press j in the terminal. If the Console now returns values, you've confirmed that the symptom came from Expo Go.

Without Android Studio, you can have EAS Build make the app in the cloud. Add a development profile to eas.json:

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "android": {
        "buildType": "apk"
      }
    }
  }
}

eas build --profile development --platform android

I set buildType to apk so the result can be installed on a device directly. Once the build completes, install it from the QR code or link on the build page.

What a development build costs you

The workaround isn't free. With Expo Go you scan a QR code and you're running. With a development build you wait for an initial build, and you rebuild whenever native dependencies change.

When you're checking screens dozens of times a day, that wait adds up. Still, as an indie developer I've found that guessing at fixes without a working debugger costs far more over time.

If you can't switch right now

Some days there's no room to move to a development build. In that case, accept the symptom and use what still works.

Log. Put console.log at the points that matter and read them in the Metro terminal. It's less comfortable than a debugger, but you can follow state changes.
Check logic on iOS. The report is limited to Expo Go on Android. Verify the logic on iOS and use a real Android device only for Android-specific parts.
Follow the issue. If a fix lands, the issue will move. Subscribe, and you'll know when it does.

One next step

When the debugger goes quiet, the first thing to do isn't opening your code. Run the same steps once on iOS and once in an empty project. That alone tells you whether to look at your side or at the environment.

Create one fresh project today, open it in Expo Go on Android, and press j. Either result tells you what to do next.

If DevTools works for you, there's a nice use for it beyond debugging: checking light and dark mode through emulation. I wrote that up in another article, if you'd like a reason to enjoy the debugger once it's back.

When DevTools Stays Silent in Expo Go on Android, Suspect the Runtime Before Your Code