[FEATURE] Configurable delay before Remote Control mobile push (keep interactive Approve/Cancel)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Remote Control's mobile push notifications (the interactive Approve/Cancel push for permission prompts, and the proactive "Claude decides" push) fire immediately, with no way to delay them. If I'm actively at my Mac and about to answer in the CLI within seconds, I still get buzzed on my iPhone and Apple Watch Ultra every time.

Today the only way to suppress these is presence-based (CLAUDE_CLIENT_PRESENCE_FILE, added in v2.1.181) tied to screen lock/unlock. That doesn't fit workflows where the display sleeps after a period of inactivity (e.g. 30 minutes) while I'm still on the same network/at the desk, or where I simply want a short grace period before escalating to mobile — not a binary present/away switch.

Related closed requests (#7460, #25802) asked for a similar delay, but scoped to local terminal-bell/desktop notifications, not the Remote Control mobile push+Approve/Cancel channel. #29438 asks for reliable mobile push delivery but doesn't address delay/threshold. None of the open issues combine "delay before mobile push" with "keep the interactive Approve/Cancel capability."

Proposed Solution

Add a configurable grace period that gates only the Remote Control mobile push (proactive + permission-required), independent of the CLAUDE_CLIENT_PRESENCE_FILE presence mechanism:

1. When a push-worthy event occurs, start a short timer (e.g. default 60s, configurable via /config or a settings.json key like pushNotifDelaySeconds).
2. If the user responds locally in the CLI (answers the permission prompt, sends a message) before the timer elapses, the queued mobile push is cancelled — no buzz at all.
3. If the timer elapses with no local response, the mobile push fires as it does today, including full interactive Approve/Cancel.
4. 0 (or omitted) preserves current immediate-push behavior.

This is distinct from the presence-file mechanism: presence file suppresses pushes for as long as you're "at the machine" (tied to lock/unlock), while this proposal adds a short buffer around each individual event regardless of lock state — useful for setups where the display sleeps well before the user actually leaves (e.g. 30-minute display-off timers).

Alternative Solutions

• CLAUDE_CLIENT_PRESENCE_FILE (existing): binary presence switch, not a timed grace window; doesn't help when display-off lags far behind actual "away" state.
• Disabling native push and building a custom relay off the Notification hook: loses the native interactive Approve/Cancel action entirely, since hooks fire as observers after the native push dispatch rather than gating it — a strictly worse workaround.

Priority

Low - Nice to have

Feature Category

Configuration and settings

Use Case Example

1. I'm at my Mac working; my display sleeps after 30 minutes of inactivity but I might still be nearby or step away for longer.
2. Claude Code hits a permission prompt.
3. With pushNotifDelaySeconds: 60 set, the push is queued, not sent immediately.
4. If I answer in the CLI within 60s, no mobile notification is ever sent.
5. If I don't respond within 60s, the interactive Approve/Cancel push fires on my phone/watch as normal.

Additional Context

Related: #7460, #25802 (local notification delay, closed/inactive), #29438 (mobile push reliability for Remote Control, open, no delay angle).