Android app parity with desktop: eleven filed gaps, one underlying problem

The official Claude mobile app on Android should reach feature parity with the desktop experience. This is explicitly not a request for a terminal emulator, a local CLI binary, or Termux environment support; those are distinct, already-tracked concerns. It is about the graphical mobile app functioning as a first-class client capable of managing and driving remote sessions reliably, rather than acting as a degraded companion screen.

Why this is filed as one issue

The individual gaps listed below have each been filed as separate bug reports and feature requests. In isolation, each ticket reads like a minor papercut. Taken together, however, they reflect a single structural problem: the Android client significantly trails the desktop client across state visibility, command support, and error handling. A previous issue requesting comprehensive mobile parity (#67946) was closed automatically by the inactivity bot rather than through an explicit product decision, and the bot's closure notice specifically invited opening a new issue if the gaps remained relevant.

The gaps, as already filed

| Issue | Gap |
| --- | --- |
| #85911 | app shows no session model or effort state; the model selector is disconnected from the actual session config |
| #86686 | remote-connect sessions started from the Android app silently override the selected model with Sonnet 5.0 |
| #88018 | slash-command messages render without their arguments |
| #82854 | /context does not work; /usage blocks the session |
| #85091 | /feedback is categorically unavailable over Remote Control, with no alternative path |
| #80549 | the app shows an offline host as "connected"; the prompt hangs instead of failing fast |
| #78669 | infinite loading spinner instead of an error when the session runner has died |
| #83610 | desktop-to-mobile session sync is stale or missing for some conversations |
| #87340 | computer-use access requests cannot be approved from mobile |
| #87952 | no visibility into which subagents are currently running |
| #86292 | cloud environment selector allows switching and creating, but not editing existing environments |

The pattern

These eleven issues fall into three distinct categories:

1. State that exists in the session but is not surfaced or is surfaced wrongly. Examples include absent model and effort indicators (#85911), missing subagent execution state (#87952), and desynchronized conversation history (#83610).
2. Controls that exist on desktop but are missing or inert on mobile. Core capabilities like computer-use authorization (#87340), slash-command execution with arguments (#88018, #82854, #85091), cloud environment configuration (#86292), and model selection (#86686) are non-functional or omitted.
3. Failure states that present as hangs rather than as errors. Disconnected runners (#78669) and offline hosts (#80549) result in infinite spinners and frozen inputs instead of immediate, actionable error states.

The failure state hangs are particularly costly on a mobile device. On a desktop, a developer encountering a stalled turn can switch to a shell, check active processes, or read the local session logs to determine what failed. On a phone, an indefinite loading spinner provides no diagnostics, leaving the user unable to tell if the remote host is computing, awaiting input, or dead.

What parity would mean here

A functional baseline for mobile parity requires the following:

• The app displays the true model and effort settings of the active session and can modify them directly.
• Slash commands execute identically to the desktop client or explicitly state that they are unsupported.
• Every host, network, or runner failure surfaces as an explicit error message instead of an indefinite spinner.
• A session's active work, including tool execution and running subagents, is visible to the user.

A modern phone has the hardware and network capabilities to handle remote developer workflows, and for many users, it is the only device physically present when an intervention or review is required. Treating the Android application as a secondary companion screen rather than a viable client is the limiting decision, not the device itself. This issue was written and filed from an Android phone, driving a remote desktop session while away from home.