fix(pi): observe tool events instead of registering a bash tool

[ellie]

The pi extension previously registered its own bash tool via pi.registerTool(createBashTool(...)). Pi only allows one extension to own a tool name, so any other extension that also provides a bash tool (sandboxes, RTK implementations, remote runners) failed to load with:

Tool "bash" conflicts with ~/.pi/agent/extensions/atuin.ts

Rewrite the extension to use pi's extension events instead:

• tool_call starts an Atuin history entry for bash commands, keyed by tool call ID
• tool_execution_end closes the entry with the exit code recovered from the result status line ("Command exited with code N", aborted -> 130, timed out -> 124). tool_execution_end is used rather than tool_result because it also fires when another extension blocks the call, so started entries are always closed.

Fixes #3556

Checks

• I am happy for maintainers to push small adjustments to this PR, to speed up the review cycle
• I have checked that there are no existing pull requests for the same thing

[greptile-apps]

Greptile Summary

Fixes the pi extension's tool-name conflict by switching from pi.registerTool(createBashTool(...)) to observing tool_call / tool_execution_end events, so the extension coexists with any other bash-tool provider. Exit code recovery is handled via regex parsing of the result status line.

• The conflict fix is correct and the event-based design is clean; exitCodeFromResult covers the documented status-line formats (exited/aborted/timed-out) with sensible fallbacks.
• The async tool_call handler awaits startHistory before calling pending.set, which can race against tool_execution_end for fast-completing commands if pi does not guarantee that async handlers are fully awaited before dispatching subsequent events.

Confidence Score: 3/5

Safe to merge for the conflict fix, but the async handler ordering in the tool_call event is worth confirming against pi's event guarantees before shipping.

The core motivation (conflict fix) is solid. The one concern worth addressing is whether pi awaits async tool_call handlers before dispatching tool_execution_end: if it does not, fast bash commands can leave Atuin history entries permanently open. The answer hinges on pi's event semantics, which is not verifiable from this repo alone.

crates/atuin/contrib/pi/atuin.ts — the async pending.set / tool_execution_end ordering

Important Files Changed

Filename	Overview
crates/atuin/contrib/pi/atuin.ts	Rewrites from a registered bash tool to event observation; fixes the tool-name conflict but introduces a potential race between the async tool_call handler and tool_execution_end for fast commands.
docs/docs/guide/agent-hooks.md	Documentation updated to reflect the new event-based approach; accurate and concise.

_{Reviews (1): Last reviewed commit: "fix(pi): observe tool events instead of ..." | Re-trigger Greptile}

[greptile-apps]

Race: pending.set may lose the run against tool_execution_end

startHistory is awaited inside the tool_call handler, so pending.set only runs after the atuin process exits (up to ATUIN_TIMEOUT_MS = 10 s). If pi's event system does not await async handlers before dispatching subsequent events — which is the norm for JS EventEmitter-style APIs — a fast-completing command can trigger tool_execution_end while startHistory is still in-flight. pending.get returns undefined, the entry is silently skipped, and endHistory is never called, leaving the Atuin record open.

Consider storing a Promise<string | undefined> in pending immediately (before the await) and resolving it in tool_execution_end — or confirm that pi guarantees it awaits all async tool_call handlers before dispatching tool_execution_end.