Add opt-in command approval alert hook

[jpia]

When a shell command requires approval, the current flow pauses for user confirmation. If late-cli is running in a background terminal or another window, the approval prompt can be missed for a while.

I’d like to propose an opt-in config hook that runs a user-defined shell command whenever approval is requested. This would let users trigger a macOS spoken alert, a desktop notification, or any custom script the user deems appropriate.

Examples:

• mac: say 'Yo, I am late. I need some more of them approvals bruh!'
• linux: notify-send 'late-cli' 'A command is waiting for approval.'

{
  "alert_on_approval_command": "say 'Yo, I am late. I need some more of them approvals bruh!'"
}

This should be:

• disabled by default when unset, empty, or whitespace-only
• fired once per approval request
• executed asynchronously with a 10s timeout
• fire-and-forget with no blocking and no output/error surfacing
• run with the current environment, without extra injected variables

Why this seems useful

It is a lightweight, zero-dependency extension that fits the existing approval model. It does not auto-approve commands; it only alerts the user that one is waiting for consent. It also works naturally with both root orchestrator approvals and subagent-triggered approvals if the hook is placed at the shared TUI confirmation layer.

Implementation sketch

The idea is a new config field:

AlertOnApprovalCommand string `json:"alert_on_approval_command,omitempty"`

Then, when the TUI enters a confirmation state for a tool requiring approval, it triggers a helper that runs:

exec.CommandContext(ctx, "sh", "-c", cmdStr)

(or the Windows equivalent) in a goroutine with a 10s timeout and discards stdout/stderr.

Discussion points for maintainers

• Is an opt-in shell-command hook acceptable as a general alert mechanism?
• Any concerns about arbitrary user-configured shell commands being executed as a notification hook?
• Would maintainers prefer this as a generic “approval alert” hook instead of a built-in notification mode enum (adds config complexity)?

[mlhher]

Yep have been thinking about this for a while too never came to implement it. Would be perfectly fine the way you proposed (just running notify-send or the OS equivalents).

Not sure how it works on Macos but for Linux you should make sure to check that notify-send does in fact exist though. If not just printing a warning and ignoring it is valid.

One note:

exec.CommandContext(ctx, "sh", "-c", cmdStr)

Is it sh instead of the command directly so the user can script it however they want? In that case if it is left empty I would suggest to default to notify-send (on Linux and the respective defaults on other platforms) directly unless there is a reason not to I am missing.

[jpia]

In my PoC, I've allowed the user to set any command (i.e. it could be executing a bash file). I'll look into putting some guardrails and/or sensible capability-aware default behaviors. Thanks for the feedback!

[jpia]

It looks like this PR #105 introduces a hook system, so I think I'll just wait for it to get merged and see if I can just use its pattern to add a command approval hook.

[deathwish]

Don't know if it'd be useful, but here's a reasonably active library for cross-platform, multi-mode, notifications: gen2brain/beeep. The other place I'd love to be notified is when generation finishes following a call to write_implementation_plan, and maybe just on any return-to-prompt event in the orchestrator.

[mlhher]

The hook system might be suited for this or not. It really depends how you want to design the architecture. It is fine if you want to wait (or not).

I agree that getting a notification specifically for write_implementation_plan might also be something useful.