Summary
When the agent pauses to ask the user for tool-use approval (e.g. shell commands, file writes), there is no hook event emitted. External integrations cannot distinguish between "tool is executing" and "tool is awaiting user permission."
Current behavior
The hook lifecycle for a tool that requires approval:
preToolUse fires → external system assumes agent is working- Agent displays approval prompt and waits (no event emitted)
- User approves/rejects
postToolUse fires (or stop on rejection)
During step 2, which can last minutes, there is no signal to external consumers.
Requested behavior
Emit a new hook event (e.g. toolApproval or permissionPrompt) when the agent is blocked waiting for user approval. This would allow external tools to show an "attention needed" state.
Context
Other CLI agents with hook systems already provide this:
- Claude Code:
PermissionRequest / Notification(permission_prompt)
- Gemini CLI:
Notification(ToolPermission)
The existing Kiro/Q CLI hook set (agentSpawn, userPromptSubmit, preToolUse, postToolUse, stop) covers the working/idle lifecycle well, but the attention/approval gap is the missing piece for complete status tracking.
Summary
When the agent pauses to ask the user for tool-use approval (e.g. shell commands, file writes), there is no hook event emitted. External integrations cannot distinguish between "tool is executing" and "tool is awaiting user permission."
Current behavior
The hook lifecycle for a tool that requires approval:
preToolUsefires → external system assumes agent is workingpostToolUsefires (orstopon rejection)During step 2, which can last minutes, there is no signal to external consumers.
Requested behavior
Emit a new hook event (e.g.
toolApprovalorpermissionPrompt) when the agent is blocked waiting for user approval. This would allow external tools to show an "attention needed" state.Context
Other CLI agents with hook systems already provide this:
PermissionRequest/Notification(permission_prompt)Notification(ToolPermission)The existing Kiro/Q CLI hook set (
agentSpawn,userPromptSubmit,preToolUse,postToolUse,stop) covers the working/idle lifecycle well, but the attention/approval gap is the missing piece for complete status tracking.