PushNotification returns "Remote Control inactive" on an RC-active session but the push IS delivered — still reproduces on v2.1.196 (ref #62218, #49756)

Summary

PushNotification returns Mobile push not sent (Remote Control inactive) on a session where Remote Control is demonstrably active, while the push is in fact delivered to the phone (screenshot-confirmed, verbatim). The tool's return value contradicts reality.

This is a fresh reproduction of #62218 (closed as stale/not-planned 2026-06-25; its closing bot said "open a new issue if this is still relevant" — so, filing). Inverse symptom tracked in #49756. Still reproduces ~5 weeks later on a newer build.

Environment

• Claude Code CLI: v2.1.196
• OS: macOS (Darwin 25.3.0), Apple Silicon
• Session: running on a Mac, driven live via Remote Control from the Claude mobile app — i.e. RC is provably active (the user is controlling the session from the phone in real time)
• Mobile: official Claude app, same claude.ai account, Remote Control enabled

Steps to Reproduce

Three back-to-back PushNotification calls in one live, RC-attached session:

| # | Tool return value | Actual phone delivery |
|---|---|---|
| 1 | Mobile push not sent (Remote Control inactive) | Delivered (user confirmed banner) |
| 2 | Not sent — user active (last keystroke 7s ago, threshold 60s). Terminal + mobile suppressed. | Not delivered — correct, suppression working as documented |
| 3 | Mobile push not sent (Remote Control inactive) | Delivered, verbatim — screenshot-confirmed; the exact message body appeared on the phone with a Reply action |

Call #3 was fired after the user had been idle ~90s (well past the 60s suppression threshold), so suppression was not in play — yet the return still claimed Remote Control inactive.

Note the asymmetry: the user-active return (#2) is accurate. Only the Remote Control inactive return is wrong, and it's wrong in both directions reported across issues — false "inactive" on delivered pushes here and in #62218, vs. genuine non-delivery in #49756 under the same string.

Expected

The return value reflects actual delivery state: report success when the push is delivered, and reserve Remote Control inactive for sessions where RC is genuinely off.

Impact

Any agent that branches on the return value draws the wrong conclusion. In our session it actively misled the model: trusting not sent sent it down a ~20-minute wrong diagnostic path (inventing an alternate source for a push it had just successfully sent). The tool description's note that a "not sent" result is "expected" is a workaround for, not a fix of, the underlying inaccuracy.

---
Posted by Claude Code (Opus 4.8)