outboundctl status
What outboundctl status prints, the single fields it reports for MDM inventory, checking and starting the background agent, and writing a diagnostic archive.
outboundctl status reports the saved network filter configuration and rule count in a script or a support session:
outboundctl statusoutboundctl status --output jsonoutboundctl status --ea <field>The command reads what it can without special privileges. It never talks to the filter extension. The background agent owns that connection.
The output
Section titled “The output”filter: enabledrules: 41filter: one of four values.
enabled: the network filter configuration exists and is switched on.disabled: the configuration exists but is switched off.not configured: no provider configuration was returned. This does not tell you whether a configuration existed in the past.unknown: the configuration could not be read. A tool without the Network Extension entitlement often cannot load it, so unknown is the honest answer and never a disguise for “off”. A load that has not answered within 3 seconds is reported as unknown too.
rules: the number of rules in the rule store, or unknown (reason) when the file cannot be read. The count is the whole store, including managed, blocklist and rule-group rules.
The agent line
Section titled “The agent line”A third line appears only when the background agent is off because someone quit it on purpose:
agent: off (quit from the menu bar). To start it, open Outbound and click Start Agent.status never starts the agent. If a command needs the agent (a blocklist refresh, for example) while it is off, that command says so in its own output.
Checking and starting the agent
Section titled “Checking and starting the agent”outboundctl agent statusoutboundctl agent startagent status says whether the background agent is marked stopped. agent start opens the agent from the installed app and prints “Opened the Outbound background agent.” There is no agent stop: stopping protection from a command is not offered, so use the menu bar in Outbound.
Structured status and MDM inventory
Section titled “Structured status and MDM inventory”status --output json (or --json) prints a fuller snapshot as one JSON object: app version and build, whether the filter is enabled and the state of its system extension, the mode, the active profile, when a pause ends, rule counts, unapproved rules, items waiting in Review, managed keys, the managed feed, the outboundctl changes setting and where it came from, and DNS.
status --ea <field> prints one of those fields as plain text, for an MDM inventory script such as a Jamf extension attribute. The fields are app_version, app_build, filter_enabled, extension_state, mode, active_profile, paused_until, rules, unapproved_rules, review_waiting, managed_keys, managed_feed, cli_changes, cli_changes_source and dns. A value that can’t be read prints unknown, and a field that holds several values prints as JSON. See inventory and diagnostics.
Diagnostic archive
Section titled “Diagnostic archive”outboundctl diagnose --out <file.zip> [--minutes 30] [--include-hosts]Writes a zip archive for a support case: the structured status, the version, managed preferences, rule and blocklist counts, the system extension list and Outbound’s log for the last 30 minutes, or the number of minutes you choose. Host names, IP addresses, email addresses and user folder names in the log are replaced with [redacted], and so are the managed feed address and the active profile’s name. --include-hosts leaves the log text as it is. The archive is readable only by you, and outboundctl never overwrites an existing file. When it is done, it prints the file’s path and size.
Exit status
Section titled “Exit status”0 in every case where the command ran, including unknown readings. The unknowns are findings, not failures: status prefers a qualified answer over a wrong one.
An enabled result describes the configuration, not a live health check of the filter process. Extra arguments, or an unknown --ea field, are rejected with exit 64.