Skip to content

When you don't answer

What a connection gets when its alert times out, or when the background agent is not running.

Outbound 1.3.0 · Updated

An alert cannot wait forever. The paused connection has a deadline, and when it passes the network filter decides on its own. The filter enforces that, so the decision stands if Outbound is busy or quitting.

How long an alert waits depends on the connection:

  • TCP: Settings › Alerts › Wait for an answer. The stepper runs from 15 to 120 seconds in steps of 5, and starts at 60. The label shows the current value as “(N) seconds”.
  • UDP: 8 seconds, not adjustable.

The gauge in the alert shows the seconds left and says “Allows automatically” or “Blocks automatically”. In the last ten seconds it fades on each even second, unless Reduce Motion is on. After the deadline the gauge reads “Already decided” and “Your answer sets a rule”.

Settings › Alerts › If I do not answer decides, and the picker is disabled in Strict:

  • Allow once (the default): the filter lets the connection through once and adds it to Review as “No answer in time”.
  • Block once: the filter stops the connection, and Review records it the same way.

Once is literal: nothing is remembered, and the next connection asks again.

If you need longer to decide, Stop Countdown beside the countdown asks the filter for more time, once per connection. The alert then shows the new time, and what the connection gets if you still have not answered. Minimizing an alert does not stop its countdown (Several alerts at once). Strict always blocks at the deadline, whatever this picker says. The caption under the control is built from the current choice. It starts “An alert waits for your answer (TCP: the time above, UDP: 8 seconds). After that the filter itself allows the connection once and adds it to Review. Strict always blocks.” When the choice is Block once, that sentence says “blocks” instead of “allows”. Two further sentences can follow: the filter has not confirmed the timeout yet, or it is still using the previous timeout until the change is approved.

If you quit the background agent, it crashes, or the Mac has not started it since login, nobody can be asked. Settings › Alerts › Without the background agent offers:

  • Same as above (the default): the same action as If I do not answer.
  • Allow
  • Block

The picker is disabled in Strict. The caption under it:

Your rules still apply. For other connections, Learn allows and Strict blocks. Ask uses this choice, but blocks apps it cannot identify.

In Ask, a program with no signing identity and no path is blocked, and an identified program follows this choice, or If I do not answer when this is Same as above.

A program whose code no longer matches the build pinned by an active path rule, and that nobody can approve, is blocked while the agent is gone. It is also blocked when its alert times out, whatever If I do not answer says. Learn’s ordinary new connections never reach this choice: they are allowed, as Learn does. A rule that already matches still decides, because the filter enforces rules without the agent.

The menu bar panel’s Quit Background Agent (or Quit Outbound, when no window is open) asks first. The dialog is “Quit the background agent?” with Quit Agent and Cancel, and a suppression box, Don’t ask again. The text says your rules keep applying because the network filter runs without the agent, and that alerts and the menu bar item stay off until you start the agent again: open Outbound, click Start Agent in its window, or log in again. It then says what new connections get, in the words of the current mode: allowed, as Learn does; blocked, as Strict does; or, in Ask, allowed or blocked without asking (Settings › Alerts), with programs Outbound cannot identify blocked.

Don’t ask again skips the dialog from then on. Settings › General › Ask before quitting the background agent turns the question back on.

A preference key, OutboundAlertAutomaticConfirmationSeconds, can apply the alert’s preselected answer after a set number of seconds. Outbound reads it as a whole number and confirms automatically when it is from 5 to 60. A missing key or a number outside that range confirms nothing. The preselected answer is Block unless OutboundAlertDefaultAction stores allow. The timer never confirms Allow while unblocking still needs your approval. Outbound has no switch for this in its interface. The approval gate itself is in Security.