Summary

Wire up the existing before_tool_call and after_tool_call plugin hooks so they actually fire during the agent execution loop. These hooks were defined in src/plugins/hooks.ts but never invoked.

What changed

New file: src/agents/pi-tools.hooks.ts

A tool wrapper module (following the same pattern as pi-tools.abort.ts) that wraps each tool's execute method to fire plugin hooks:

• wrapToolWithHooks(tool, hookRunner, ctx) — wraps a single tool
• wrapToolsWithHooks(tools, hookRunner, ctx) — wraps an array; returns the original array unchanged if no hooks are registered (zero overhead)

Modified: src/agents/pi-embedded-runner/run/attempt.ts

• Moved hookRunner initialization earlier (before splitSdkTools) so it's available for tool wrapping
• Both builtInTools and customTools are wrapped before being passed to createAgentSession
• Extracted hookAgentId to avoid repeated sessionKey.split(":") calls

How it works

before_tool_call

Fires before each tool executes. Plugin handlers receive { toolName, params } and can:

• Block the call: return { block: true, blockReason: "..." } → tool is skipped, a synthetic [Tool call blocked] ... result is returned to the model
• Modify params: return { params: modifiedParams } → the modified params are used instead

Handlers run sequentially in priority order. If any handler blocks, the tool is not executed.

after_tool_call

Fires after each tool returns (or throws). Plugin handlers receive { toolName, params, result, error, durationMs }.

This is fire-and-forget (void hook) — handlers run in parallel and failures are caught and logged.

Plugin author usage

// In a plugin's hooks registration:
{
  hookName: "before_tool_call",
  handler: async (event, ctx) => {
    // Log all tool calls
    console.log(`Tool ${event.toolName} called with`, event.params);

    // Block dangerous tools
    if (event.toolName === "exec" && isSuspicious(event.params)) {
      return { block: true, blockReason: "Blocked by security policy" };
    }

    // Or modify params
    return { params: sanitize(event.params) };
  },
}

{
  hookName: "after_tool_call",
  handler: async (event, ctx) => {
    // Post-execution logging / telemetry
    metrics.recordToolCall({
      tool: event.toolName,
      durationMs: event.durationMs,
      success: !event.error,
    });
  },
}

Safety

• Hook errors never break tool execution (caught and logged)
• Tools are only wrapped when hooks are registered (no overhead otherwise)
• Follows existing patterns: same wrapper style as wrapToolWithAbortSignal, same hook runner access as session-tool-result-guard-wrapper.ts
• No refactoring of existing code — purely additive wiring

Greptile Overview

Greptile Summary

This PR wires before_tool_call and after_tool_call plugin hooks into the embedded agent execution loop by adding a wrapToolsWithHooks wrapper that decorates each tool’s execute method. runEmbeddedAttempt now initializes the global hookRunner earlier and passes wrapped builtInTools and customTools into createAgentSession, and it also avoids repeated sessionKey.split(":") by extracting hookAgentId.

The change fits into the existing plugin-hook architecture (src/plugins/hooks.ts) similarly to other tool wrappers (e.g. abort-signal wrapping) and enables plugins to observe/block/modify tool calls and record post-execution telemetry.

Confidence Score: 3/5

• This PR is likely safe to merge, but the blocked-tool-call behavior may cause tool result pairing issues on strict providers.
• Core wiring is straightforward and follows existing wrapper patterns, but the new wrapper introduces subtle contract questions: returning a raw string on blocked calls and not emitting a toolResult tied to the toolCallId can break strict tool-call/tool-result pairing or downstream result parsing depending on provider/tooling expectations.
• src/agents/pi-tools.hooks.ts

_{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!}