[BUG] Mobile push notifications silently dropped ~50% of the time, with no client-side signal

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Mobile push notifications silently dropped ~50% of the time, with no client-side signal

Summary

PushNotification reports "Terminal notification sent. Mobile push requested."
for every send, but only about half actually arrive on the paired mobile device.
Remote Control is connected and healthy throughout (heartbeats every ~20s), and
the desktop notification delivered by the same tool works 100% of the time.

There is no error anywhere in the --debug log, and — critically — a dropped
push and a delivered push produce byte-identical client logs and identical tool
output. There is no way for a user to tell whether a notification was
delivered.

Environment

| | |
|---|---|
| Claude Code version | 2.1.220 (cc_version=2.1.220.3fc) |
| Install method | native |
| Platform | Linux 7.0.0-28-generic |
| Shell | bash |
| Session ID | b04802d7-7c2a-4467-b235-3bd089dd6dfb |
| Debug log | ~/.claude/debug/b04802d7-7c2a-4467-b235-3bd089dd6dfb.txt |

Relevant settings in ~/.claude/settings.json:

"inputNeededNotifEnabled": true,
"agentPushNotifEnabled": true

A hooks.Notification block also runs notify-send locally. That desktop path
fired every single time, including for every push below that never reached the
phone.

Reproduction

1. Confirm Remote Control is connected and phone notification permissions are on.
2. Start a session with claude --debug.
3. Switch focus away from the terminal (otherwise the tool self-suppresses).
4. Trigger a PushNotification, with a unique timestamp in the message body.
5. Repeat several times over a few minutes.
6. Observe: every call returns "Mobile push requested" and every desktop

notification appears, but only some reach the phone.

Observed results

All times local (UTC+3). Dispatch times are taken from the debug log, which is
authoritative. Each message body carried a unique stamp so arrivals could be
matched unambiguously.

| # | Dispatch (local) | Tool result | Arrived on phone |
|---|---|---|---|
| 1 | 21:16:51 | Not sent — this terminal is active | n/a (nothing transmitted) |
| 2 | 21:17:44 | Mobile push requested | YES (unstamped) |
| 3 | 21:24:23 | Mobile push requested | NO |
| 4 | 21:26:17 | Mobile push requested | NO (terminal minimized) |
| 5 (C) | 21:41:32 | Mobile push requested | NO |
| 6 (D) | 21:42:38 | Mobile push requested | YES |
| 7 (E) | 21:43:46 | Mobile push requested | YES |

Delivery rate: 3 of 6 transmitted pushes arrived. Restricted to the five
stamped, unambiguously-matched tests: 2 of 5.

Three earlier pushes in a prior session (before --debug was enabled) also
never arrived.

Possible pattern (hypothesis, not established)

The two longest idle gaps each preceded a failure: #3 came 6m39s after the
previous push and dropped; #5/C came 15m09s after and dropped. The pushes
following closely behind a successful one (#6/D and #7/E, ~1 minute apart) both
arrived.

This is consistent with the first push after an idle period being dropped —
perhaps a stale device registration or a connection that must be re-established.
However, #4 contradicts it: it was sent 1m54s after #3 and still dropped. So
the pattern is suggestive only.

Diagnostic detail

The tool emits no push-specific logging at --debug. Its entire footprint:

2026-07-29T18:17:44.365Z [INFO] [Stall] tool_dispatch_start tool=PushNotification toolUseId=toolu_01XuNRnNXzX6wRk9magviCrv permissionDecisionMs=1
2026-07-29T18:17:44.365Z [INFO] [Stall] tool_dispatch_end   tool=PushNotification toolUseId=toolu_01XuNRnNXzX6wRk9magviCrv outcome=ok durationMs=0

No HTTP request, no push endpoint, no device ID, no queue entry. durationMs=0
indicates no synchronous local network call.

This footprint is byte-identical across all three outcomes — suppressed
(#1), delivered (#2, #6, #7), and dropped (#3, #4, #5). Only the timestamp
differs. Both suppressed and transmitted pushes are followed by
[remote-bridge] Sending 2 message(s), so that line reflects tool-result
batching and is NOT evidence of push transmission.

Consequence: neither the logs nor the tool result can distinguish a delivered
push from a dropped one. "Mobile push requested" is a hand-off string, not a
delivery receipt.

Remote Control connectivity is healthy. 83 CCRClient: Heartbeat sent
entries across the session, roughly every 20s, continuing past the final push
(last at 18:43:54Z). Heartbeats are present and regular around both the
delivered and the dropped pushes — bridge health does not correlate with
outcome.

No relevant errors. The only [ERROR] lines in the entire log are two
unrelated semantic-scholar MCP connection failures at startup.

Ruled out

• Terminal-focus suppression — real, but only explains #1. All dropped

pushes returned "Mobile push requested", not "Not sent". #4 dropped with
the terminal minimized.

• Disabled settings — both notification flags are true.
• Remote Control disconnection — heartbeats confirm an active bridge across

both delivered and dropped pushes.

• Phone-side permissions — notifications are allowed for the app, and other

pushes in the same window arrived on the same device.

• Client-side errors — none logged.

Impact

The intermittency is the smaller half of the problem. The larger half is that
the failure is completely invisible: a user relying on push to be alerted when a
long-running job finishes has no way to know that half their alerts were
silently dropped, because every send reports success.

Related prior reports

Several earlier issues describe the same symptom but were closed without
resolution, all reporting deterministic total failure. None includes measured
delivery rates or debug-log analysis:

• #50949 — "Mobile push notifications not delivered despite 'Mobile push

requested' success response" (closed; labels bug, platform:linux,
platform:ios, needs-info). Closed pending information; this report supplies
the missing evidence.

• #60383 — "Remote Control: mobile push notifications never deliver despite

paired/working session" (closed as duplicate/stale).

• #57758 — "[Bug] Android push notifications not working with remote control"

(closed).

• #60208 — "Push notifications broken - mobile devices not receiving

notifications" (closed).

The new information here is that delivery is intermittent rather than total
(3 of 6 arrived), which may explain why some reports were not reproducible, plus
the finding that dropped and delivered pushes are indistinguishable in the
client logs.

Suggested fixes

1. Log the push path at --debug — endpoint, device/registration ID, HTTP

status, and the send/suppress decision. There is currently zero
observability; this investigation could not progress past "it sometimes
doesn't arrive" using local evidence alone.

1. Return a result that reflects reality. "Mobile push requested" is

returned identically for delivered and dropped pushes. Even a distinction
between "queued to bridge" and "acknowledged by service" would help.

1. Investigate the idle-gap hypothesis — whether the first push after a

period of inactivity hits a stale device registration.

1. Surface push-registration state separately from Remote Control connection

state, so "connected for control" and "registered for push" can be told
apart.

What Should Happen?

getting notifications on my phone every time.

Error Messages/Logs

Steps to Reproduce

do what it says in the "what's wrong" section

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.220

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_