Expose approval-mode metadata on tool results
Problem
When building autonomous command workflows (e.g., multi-chunk implementation with parallel subagents), the agent frequently pauses for manual tool approval. These interruptions are the primary bottleneck in autonomous execution, but there's no systematic way to identify which approvals are recurring and could be pre-authorized through permission settings or rule changes.
The agent currently cannot distinguish between tool calls that were auto-approved vs. manually approved by the user. It sees tool call → result with no metadata about the approval path. This makes it impossible for commands to self-report friction points for later review.
Proposal
Include approval metadata on tool results, indicating how the tool call was authorized. For example:
{
"approval": {
"mode": "manual" | "auto" | "hook",
"rule": "Bash(npm test)" | null
}
}
This would enable:
- Commands to log tool calls that required manual approval during execution
- Retrospective workflows to analyze approval patterns and recommend permission refinements
- Hooks or post-session summaries to surface recurring friction points
Use Case
A /implement command dispatches parallel subagents. Each subagent runs bash commands, writes files, and runs tests. After completion, a /retrospective command could consume the approval log and recommend specific settings.json permission entries to reduce interruptions in future runs — e.g., "The npm test command was manually approved 12 times across 4 subagents. Consider adding Bash(npm test) to your allow list."
Alternatives Considered
- Logging all tool calls from commands: Possible today, but without approval metadata the signal-to-noise ratio is too low — most logged calls would be non-interruptions.
PreToolUsehooks for logging: Hooks fire on every tool call regardless of approval mode, so they have the same noise problem.- Manual review of permission settings: Doesn't scale and requires the user to remember which prompts appeared during a session.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗