If a device hook template cannot install, the tools it guarded are now denied rather than allowed.
Fail-closed template handling applies only where device hook forwarding is active, which is off here.
What's wrong with this entry?
When a hook template registered by another device cannot be installed on this machine, the tool calls it was meant to guard are now denied instead of being allowed through unchecked. This sits behind the same gate as device hook forwarding, so it only applies where that forwarding is active.
- Triggers when the template is still awaiting upload, its interpreter is unavailable, or preparing it fails or times out.
- The blocking stand-in is registered on the same matcher as the real template and reports outcome
stand_in_blockedon the tengu_device_hook_template_run telemetry point. - At run time a template that fails cleanly either blocks the call (for fail-closed templates) or attaches an explanation from a fixed reason list, such as "its file no longer matched what was verified", "its interpreter can no longer be trusted" or "it took too long".
could not be installed on this worker; matching calls are blocked until it is (register again to retry)
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.234
SessionEnd hooks lose the
bypass_permissions_disabledreasonBoth mention hook
-
v2.1.236
Hooks and Ctrl-C go quiet once shutdown has started
Both mention hook
-
v2.1.236
Shutdown seals transcript writes and gives SessionEnd hooks more time
Both mention hook