PushNotification reports "Remote Control inactive" (no_transport) in sessions served by `claude remote-control`

Summary

In a session served by claude remote-control (server mode), the PushNotification tool always returns "Mobile push not sent (Remote Control inactive)" (disabledReason: no_transport), even though the session is connected from the Claude mobile app / claude.ai and permission prompts are forwarded normally. The same tool pushes fine from an interactive session started with claude --remote-control.

Environment

• Claude Code 2.1.263 (native installer), Linux (Ubuntu) and macOS; reproduced on 2.1.250–2.1.263
• Started with claude remote-control --permission-mode auto --name <name> inside tmux
• ~/.claude/settings.json: "agentPushNotifEnabled": true, "inputNeededNotifEnabled": true
• Mobile app installed and signed in with the same account

Steps to reproduce

1. claude remote-control --name test
2. Open the session from the Claude mobile app and send: notify me on my phone with a push notification
3. The model calls PushNotification; the tool result is Mobile push not sent (Remote Control inactive).

Expected: the push is sent (the docs say "When Remote Control is active, Claude can send push notifications to your phone", and server mode is the documented way to run long-lived RC sessions).

What seems to happen

Server mode spawns one child per session (claude --print --sdk-url … --input-format stream-json, CLAUDE_CODE_ENVIRONMENT_KIND=bridge). The tool decides it has a push transport only when CLAUDE_CODE_REMOTE is set, the workspace is marked remote, or the REPL-bridge-active flag is set — and that flag is only set by the interactive remote_control control-request path (/remote-control, --remote-control). A bridge-spawned child never sets it, so the tool short-circuits with no_transport before anything is sent. Elsewhere the surface detection already treats CLAUDE_CODE_ENVIRONMENT_KIND === "bridge" as equivalent to the bridge being active, so the push tool looks like the odd one out.

This is not the presence check: the tool returns no_transport before anything reaches the server, and the same server-mode session does deliver "Claude needs your permission" and "Claude has a question" (AskUserQuestion) pushes to the phone — so the account, device registration and server-side preferences are all fine. Only the proactive PushNotification path is dead.

Suggested fix

Treat CLAUDE_CODE_ENVIRONMENT_KIND=bridge (or the presence of --sdk-url under the server) as an available transport in the push tool, or have the server set the bridge-active state in the child.

Workaround

Run the one session that needs proactive pushes as claude --remote-control <name> in tmux instead of server mode.