Dangerous-command approvals can currently wait silently if the user misses the prompt.

Context

Manual approvals are safety-critical, but the CLI prompt is easy to miss when the terminal is not focused. display.bell_on_complete only rings when the agent finishes a response; it does not alert when a dangerous-command approval is waiting.

Related timeout bugfix PR: #17933. That PR keeps scope to honoring the existing approvals.timeout config. This issue is for the separate alert/notification behavior.

Current behavior

• A dangerous command opens the normal approval prompt.
• If the user misses it, the prompt eventually times out and denies.
• There is no approval-specific terminal bell, repeated alert, or notification.

Expected behavior

Add an optional approval-waiting alert that fires when an approval request is created and stops when the request is approved, denied, or times out.

A conservative config shape could be:

approvals:
  timeout: 600
  alert:
    enabled: true
    terminal_bell: true
    repeat_seconds: 10
    repeats: 6

Proposed boundary

• Default off, or at most a single terminal bell if maintainers prefer a low-friction default.
• V1 should be cross-platform and low-risk: terminal bell is enough.
• Desktop notifications / macOS sounds can be a later opt-in path or plugin hook consumer.
• Avoid arbitrary alert_command in v1 unless there is a stronger sandbox/trust story; running configured shell commands during dangerous-command approval is security-sensitive.
• The alert must not auto-approve, bypass, or weaken the existing approval gate.
• Repeated alerts should be rate-limited and must stop on approve/deny/timeout.

Acceptance sketch

• CLI prompt_toolkit path triggers the alert when _approval_state is created.
• Gateway approval path can either use the same hook/event or explicitly stay out of scope for v1.
• Tests cover start/stop behavior and timeout cleanup.