You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/configuration/local-sudo.md
+5Lines changed: 5 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -53,6 +53,9 @@ providers:
53
53
local-presence:
54
54
provider: local-presence
55
55
enabled: true
56
+
local-notification:
57
+
provider: local-notification
58
+
enabled: true
56
59
```
57
60
58
61
For full local macOS integration testing, install the Apple Development-signed privilege-services bundle with:
@@ -81,6 +84,8 @@ On macOS v1, timed sudo is brokered through the native privilege-services app bu
81
84
82
85
If a workflow uses an approval notifier with `provider: local-presence`, the same signed helper can trigger a macOS device-owner authentication prompt on the routed device before `authorize` runs. The result is recorded through the normal approvals path, alongside Slack and email approval callbacks. This requires the target agent to be online in an interactive login session; CI and unit tests mock the LocalAuthentication result rather than invoking biometrics.
83
86
87
+
Workflows can also opt into Thand-managed macOS notifications with `provider: local-notification` in `thand: notify`, approval notifiers, `authorize.with.notifiers`, or `revoke.with.notifiers`. These notifications are routed to the target `device_id` and posted by the signed helper through `UNUserNotificationCenter`. Broker-triggered lease notifications remain enabled separately for now.
88
+
84
89
## Account Mapping
85
90
86
91
Per-device account mappings decide which local account receives sudo.
| `to` | string or array | Yes | Recipient identity, channel, or email address |
508
+
| `message` | string | No | Notification body |
509
+
| `device` | string | No | Target device for `local-notification` |
509
510
510
511
### Notification Process
511
512
@@ -519,6 +520,9 @@ The notify task:
519
520
520
521
- **Slack**: Sends rich notifications with approval buttons
521
522
- **Email**: Sends email notifications
523
+
- **Local Notification**: Sends a macOS user notification on a routed agent device with `provider: local-notification`
524
+
525
+
`local-notification` requires a live macOS agent and a target device. Device resolution follows the explicit notifier `device` field first, then the request `device`, then request metadata `device_id`. The same routing applies when `local-notification` is used in `thand: notify`, `authorize.with.notifiers`, `revoke.with.notifiers`, or `approvals.with.notifiers` approval prompts. It uses the signed helper and `UNUserNotificationCenter`; it does not replace broker-triggered sudo lease notifications, which remain in place for now.
522
526
523
527
### Examples
524
528
@@ -527,12 +531,20 @@ The notify task:
527
531
- slack-notify:
528
532
thand: notify
529
533
with:
530
-
approvals: 1
531
-
notifiers:
532
-
slack:
533
-
provider: slack
534
-
to: "C0123456789"
535
-
message: "Access granted to user"
534
+
provider: slack
535
+
to: "C0123456789"
536
+
message: "Access granted to user"
537
+
```
538
+
539
+
**macOS Local Notification**
540
+
```yaml
541
+
- local-notify:
542
+
thand: notify
543
+
with:
544
+
provider: local-notification
545
+
to: ${ $context.user.email }
546
+
device: "${ .device }"
547
+
message: "Your local sudo request was approved"
536
548
```
537
549
538
550
**Note**: The notify task is primarily used internally by the approvals task. For standalone notifications, consider using standard Serverless Workflow `call` tasks to external APIs.
0 commit comments