Describe the feature or problem you'd like to solve
notification hooks currently cannot cancel the notification that triggered them like some other hooks can.
Proposed solution
There are certain situations where it would be nice to be able to "silence" specific notifications. Particularly the one for the end of the interaction if you know the workflow is going to automatically send another prompt later. A custom hook that looks at the notification could be leveraged for this, but the response from notification hooks is currently ignored.
I'm proposing that the notification hook work like agentStop, preToolUse, subAgentStop, and others; allow for a response from the hook that cancels the notification.
Alternatively, add an option to suppress end-of-interaction notifications if there are still scheduled prompts pending. However, as there are many reasons for notifications, it would be nice to have the notification hook match the others.
Example prompts or workflows
Example workflow that would benefit:
Some workflows require polling via scheduled prompts. In these cases, the agent schedules the next prompt, then ends the interaction with a message like "waiting for next prompt". Because the agent ended the interaction, CLI sends a notification/bell. This makes the user think there's something new going on, but it was just another poll. This may happen again when the next polling prompt finishes. A custom hook could see that there are still scheduled prompts (or a specific trigger phrase in the final turn) and suppress the notification.
Additional context
The notification hook already has a defined json response. I'm imagining adding a field such as cancel?: boolean, and reading the response code looking for 2 like the permissionRequest hook already does.
Describe the feature or problem you'd like to solve
notificationhooks currently cannot cancel the notification that triggered them like some other hooks can.Proposed solution
There are certain situations where it would be nice to be able to "silence" specific notifications. Particularly the one for the end of the interaction if you know the workflow is going to automatically send another prompt later. A custom hook that looks at the notification could be leveraged for this, but the response from
notificationhooks is currently ignored.I'm proposing that the
notificationhook work likeagentStop,preToolUse,subAgentStop, and others; allow for a response from the hook that cancels the notification.Alternatively, add an option to suppress end-of-interaction notifications if there are still scheduled prompts pending. However, as there are many reasons for notifications, it would be nice to have the
notificationhook match the others.Example prompts or workflows
Example workflow that would benefit:
Some workflows require polling via scheduled prompts. In these cases, the agent schedules the next prompt, then ends the interaction with a message like "waiting for next prompt". Because the agent ended the interaction, CLI sends a notification/bell. This makes the user think there's something new going on, but it was just another poll. This may happen again when the next polling prompt finishes. A custom hook could see that there are still scheduled prompts (or a specific trigger phrase in the final turn) and suppress the notification.
Additional context
The
notificationhook already has a defined json response. I'm imagining adding a field such ascancel?: boolean, and reading the response code looking for 2 like thepermissionRequesthook already does.