One email check hides Claude's Android debug menu

In Claude's Android app, a regular user is kept away from Anthropic's internal debug menu by one line of code that checks whether the account email ends in @anthropic.com. A teardown published on GitHub followed that check through a preference key called is_ant and found the full menu still inside the release build.

At a glance

• Among about 100 SharedPreferences keys that survived R8 optimization, one called is_ant is set to true for Anthropic email addresses and controls whether an Internal Settings entry appears in Settings.
• The menu includes GrowthBook feature flag overrides, network failure simulation, a jank overlay, age signal and push notification testing, and a switch between Production, Staging, Localhost and custom backends.
• Unlocking the menu does not get you into staging: the hostname is publicly reachable but sits behind Cloudflare Access, and the write-up names none of the feature flags it browsed.

The author takes Android apps apart out of curiosity and studied the practice for an M.Sc. thesis. Anthropic has written a lot about Claude and Claude Code, but the author found little on its blog about how the Android app is built. Anthropic's client code has drawn attention before. According to InfoQ, Claude Code CLI v2.1.88 on npm shipped with a source map pointing to its full unobfuscated TypeScript source, which Anthropic called "a release packaging issue caused by human error, not a security breach".

One email check sets is_ant and unlocks the settings entry

Android release builds usually pass through R8, which strips unreachable code and shortens class, field and method names. The app gets smaller and decompiled code gets harder to follow. SharedPreferences keys, the small named values an app stores on the device, tend to stay readable, and the author counted about 100 of them in Claude's app.

One stood out immediately: is_ant. The code that set it to true checked whether the account email ended in @anthropic.com, which strongly suggested a local marker for employee accounts. The author then traced where the key was read. One of those reads sat in the Settings screen, where the same boolean decided whether an internal settings entry was shown at all.

A relabelled "New chat" button proved the rebuilt APK worked

On a rooted device the author could have flipped the stored preference directly. Because other parts of the app were under study at the same time, the author repackaged it instead: unpack the APK, modify it, rebuild it and sign the result so it would install on a test device.

The first change was deliberately obvious. Relabelling the "New chat" button confirmed that the rebuilt app carried the edits and made it easy to tell apart from the original. The second change made the condition guarding the internal settings entry always pass. After another rebuild the entry showed up in Settings, and the screen behind it had survived optimization intact.

A floating Ant button and a jank overlay sit among the debugging tools

The tour starts with the "Internal Settings bubble". Turning it on adds a floating, draggable Ant button that opens the menu and snaps to the screen edges. It saves a trip through Settings when a debug option has to be flipped again and again.

"Show jank overlay" puts UI performance statistics on screen, wired to JankStats and Android's FrameMetrics API, so a slow interaction can be measured while it is being reproduced. "Age Signal override" offers controls for simulating different age signals, and a dedicated screen tests push notifications. The "Network Simulation" screen adds latency and forces request, upload and timeout failures on demand.

The endpoint switch offers Production, Staging, Localhost and a custom backend

The app integrates GrowthBook, and an "Override feature flag" screen lets a tester change local flag values and configurations. The author calls it one of the more interesting screens, because flags can hint at experiments and possible future features, and includes a recording of scrolling through the available overrides.

"Select API Endpoint" switches the app between Production, Staging, Localhost and a custom backend. The staging hostname was publicly reachable, but Cloudflare Access sat in front of it and required authentication. The author was most impressed by the polish: internal tools often look rough around the edges, yet these screens felt carefully designed.

Why does a preference key survive R8 when class names do not?

R8 renames code, but it leaves much of the app's data alone. A descriptive class name can shrink to a single letter, while a preference key is a string the app looks up on the device at runtime, so it usually stays as written. Picture a house where every door sign is swapped for a number but the jar labels in the pantry stay readable: follow the jars and you work out what each room is for.

The flag screen applies a similar idea to product behaviour. GrowthBook's documentation says its flags change app behaviour without shipping new code. They can target users by attributes and conditions, roll changes out gradually, run A/B tests and differ between dev, staging and production environments. A local override lets a tester force one flag value on their own phone without affecting anyone else.

The gate lives on the phone, while staging stays behind Cloudflare Access

The is_ant check reads as a convenience gate more than a security boundary: anyone willing to rebuild the APK can see the menu, and the real lock appears to sit on the server, where Cloudflare Access guards staging. In our view, the flag override screen is where the real clues to future features sit, yet the write-up does not name a single flag.

What the flag list still hides

The author says there is more left to explore in the menu, but no follow-up post or date has been announced. The open question is the GrowthBook list itself: which experiments it names, and whether any of them turn into features in Claude's Android app. Neither answer is in the current write-up, and both depend on a closer look at the overrides.