Feature request: Add agent_id to PreToolUse/PostToolUse hook input for context-aware tool policies

Problem

The agent_id and agent_type fields are currently only available in SubagentStart and SubagentStop hook events. They are not present in PreToolUse, PostToolUse, or any other tool-level hook input.

This means there is no way for a hook to determine whether a tool call originates from the main conversation or from a sub-agent. All tool calls — regardless of origin — present identical input fields.

Use Case

I run an orchestration-only workflow where the main Claude Code conversation window handles planning and dispatching, while all file modifications are performed by sub-agents. The main window should never execute Edit, Write, or state-changing Bash commands directly.

I wanted to enforce this with a PreToolUse hook:

• Main conversation calls Edit or Write → hook returns deny with a message explaining the policy violation
• Sub-agent calls Edit or Write → hook allows it

This is impossible today because the hook input contains no field that distinguishes the caller.

What We Tested

We deployed a diagnostic PreToolUse hook (Node.js) that logged all top-level fields from the JSON input received on stdin. We triggered Edit and Write calls from both the main conversation window and from a sub-agent spawned via the Agent tool.

Result: Both cases produced identical input fields:

session_id
transcript_path
cwd
permission_mode
hook_event_name
tool_name
tool_input
tool_use_id

No agent_id, no agent_type, no nesting depth, no other discriminator. The hook has no way to tell the two contexts apart.

Proposed Solution

Add agent_id and agent_type to the common hook input schema for all hook events (PreToolUse, PostToolUse, Notification, etc.), not just SubagentStart/SubagentStop.

Behavior:

| Context | agent_id | agent_type |
|---|---|---|
| Main conversation | null or absent | null or absent |
| Sub-agent | Populated (matches the value from SubagentStart) | Populated |

This is additive and backward-compatible. Existing hooks that don't inspect these fields are unaffected.

Impact

This would enable:

• Tool-level policy enforcement by context — block destructive tools in the main window while allowing them in sub-agents
• Differentiated validation rules — e.g., stricter Bash command filtering in the main conversation, permissive in agents that are expected to run builds/tests
• Audit logging with agent context — correlate tool calls to the specific sub-agent that made them, useful for debugging multi-agent workflows
• Agent-scoped guardrails — different sub-agents could have different tool policies based on their agent_id or the task they were spawned for