Remote Control: CLI reports "Mobile push requested" but Android never receives it (still reproduces on 2.1.233)

Filing a new issue as #52880 asks ("Closing for now — inactive for too long. Please open a new issue if this is still relevant."). It is still relevant: reproduced today on a different phone, a different OS and a much later CLI build. The last comment on #52880 is 2026-08-09, "This still doesn't work".

Summary

PushNotification returns Terminal notification sent. Mobile push requested. The desktop notification appears. The Android phone never receives anything. Android notification history holds zero records for com.anthropic.claude.

The Remote Control data path itself is healthy: the phone opens sessions on the machine, drives them, and shows their output live. Only the notification step fails.

Environment

| | |
|---|---|
| Claude Code | 2.1.233 |
| Host | macOS 26.4.1, Darwin 25.4.0, Apple silicon |
| Phone | Pixel 6 (oriole), Android 17 (SDK 37) |
| Claude Android app | 1.260813.10 (versionCode 26081310) |
| Account | same account on both, personal plan |

Steps to reproduce

1. In a terminal session run /remote-control. The session connects.
2. Confirm both toggles are on in /config: Push when Claude decides, Push when actions required.
3. Put the Android app in the background with the Home button. Do not force-close it.
4. Leave the terminal untouched for more than three minutes, so the presence gate opens.
5. Trigger PushNotification.

Expected

A notification banner on the phone.

Actual

The CLI prints:

Terminal notification sent. Mobile push requested.

The phone shows nothing. Polling for a full minute after each attempt:

$ adb shell dumpsys notification --noredact | grep -c 'pkg=com.anthropic.claude'
0

Two clean attempts, both identical.

Ruled out

Each item was measured, not assumed.

| Layer | Evidence |
|---|---|
| Both toggles | agentPushNotifEnabled: true, inputNeededNotifEnabled: true in ~/.claude/settings.json |
| Server feature flags | tengu_kairos_push_notifications and tengu_kairos_input_needed_push both true in ~/.claude.json |
| Android permission | POST_NOTIFICATIONS: granted=true |
| App standby bucket | am get-standby-bucket returns 10 (ACTIVE) |
| Battery optimization | exempted: dumpsys deviceidle whitelist +com.anthropic.claude |
| Do Not Disturb | off — settings get global zen_mode returns 0 |
| FCM transport | connected=mtalk.google.com:5228, and other apps deliver notifications during the same window |
| App channels exist | completion, dispatch, compass, marketing, all importance 4 |
| Push token | app brought to the foreground, then /remote-control reconnected after it, per the docs note about "No mobile registered" |
| Presence gate | open — the error text changes away from this terminal is active |
| Remote Control gate | open — the error text changes away from Remote Control inactive |

This matches what #52880 concluded: the transport works, the notification-posting step does not. Either the backend sends a data-only payload with no notification payload, or the app never posts it to the system tray.

Two findings that are not yet written down anywhere

Both cost hours to find, and both make the bug look like a configuration mistake when it is not.

1. CLAUDE_CLIENT_PRESENCE_FILE is additive to the terminal-active gate, not a replacement.

The env-vars page says "When the file is absent or unreadable, notifications are sent as normal", which reads as though the marker file becomes the only presence rule. It does not. With the variable set and the file absent, the terminal-active gate still blocked the push. The variable can only make pushes rarer, never more common. Worth stating on the page.

2. A session spawned by a claude remote-control server counts as "Remote Control inactive" once the phone app is backgrounded.

This makes the most natural test impossible. Start a task from the phone, put the phone in your pocket, wait for the push — and the push is refused with Mobile push not sent (Remote Control inactive), because backgrounding the app detached the only client that session had. The session shows Disconnected in the app's own list.

Only an interactive terminal session with /remote-control holds RC from the machine side, and only that configuration reaches the Mobile push requested state at all. If this is intended, the Remote Control page should say so, because "walk away and let it push" is exactly the workflow the feature promises.

Related

• #52880 — Android, closed as stale, last comment 2026-08-09 "This still doesn't work"
• #57758 — Android, closed as duplicate of #52880
• #60383 — same symptom, closed as duplicate
• #60208 — same symptom, closed as stale
• #50949 — iOS, the head of the duplicate chain