Pi bridge drops tool name/input, causing false circuit-breaker constraints
Environment
- Munder Difflin: packaged macOS app, v0.5.2
- Pi: @earendil-works/pi-coding-agent v0.85.1
- Node.js: v26.8.2
- Observed with two Pi agents using different models (GLM 5.3 Flash and Kimi K3)
Actual behavior
Agents performing different successful tool calls are warned and constrained as though they are repeating one identical call. Example:
looping: 13× identical tool call (?)
The agents completed their assigned artifacts and handoffs. The 13 sampled tool calls were distinct.
Expected behavior
The breaker should distinguish calls by the actual tool name and input, while still detecting genuinely repeated calls.
Reproduction
- Launch a Pi agent in Munder with working credentials and the default eight-call repetition threshold.
- Have it perform at least eight different successful tool calls, such as reading different files and running different commands.
- Let the breaker evaluate on successive heartbeat ticks.
- Observe an unknown-tool
(?) repeated-call warning and escalation to constrained.
Diagnosed cause
Pi's tool_call and tool_result events expose toolName and input.
Munder's generated PI_EXTENSION reads ev.name or ev.tool.name instead of ev.toolName. Its tool_result → PostToolUse payload also omits tool_input entirely.
HookServer feeds the breaker from PostToolUse. Consequently every Pi completion is recorded with undefined tool name and input. CircuitBreaker.toolKey maps them all to the same unknown-tool/empty-input fingerprint.
Both fields need correction: fixing only the name would still misclassify distinct consecutive bash commands.
Verification performed
Replayed 13 actual distinct tool-call records through the installed generated bridge in a JavaScript VM with a mocked socket, then through the exact installed CircuitBreaker implementation:
| Mapping |
Unique fingerprints |
Repeat count |
Result after two evaluation ticks |
| Current bridge |
1 |
13 |
Constrained |
| Corrected name and input, in memory only |
13 |
1 |
Healthy |
| Corrected mapping, eight genuinely identical calls |
1 |
8 |
Constrained |
Suggested fix
Use ev.toolName for the tool name on both events and include ev.input as tool_input on PostToolUse. Preserve the breaker threshold and behavior.
Fix the PI_EXTENSION generator as well as regenerated bridges: installPiHooks rewrites each agent's bridge during startup. Add regression coverage for varied Pi tool calls and true repeated calls. Existing sessions also need the corrected bridge loaded and stale breaker state cleared or recovered.
This is a confirmed local diagnosis and isolated proposed-fix replay. No production/app patch has been installed yet.
Pi bridge drops tool name/input, causing false circuit-breaker constraints
Environment
Actual behavior
Agents performing different successful tool calls are warned and constrained as though they are repeating one identical call. Example:
looping: 13× identical tool call (?)The agents completed their assigned artifacts and handoffs. The 13 sampled tool calls were distinct.
Expected behavior
The breaker should distinguish calls by the actual tool name and input, while still detecting genuinely repeated calls.
Reproduction
(?)repeated-call warning and escalation to constrained.Diagnosed cause
Pi's tool_call and tool_result events expose
toolNameandinput.Munder's generated
PI_EXTENSIONreadsev.nameorev.tool.nameinstead ofev.toolName. Its tool_result → PostToolUse payload also omits tool_input entirely.HookServer feeds the breaker from PostToolUse. Consequently every Pi completion is recorded with undefined tool name and input. CircuitBreaker.toolKey maps them all to the same unknown-tool/empty-input fingerprint.
Both fields need correction: fixing only the name would still misclassify distinct consecutive bash commands.
Verification performed
Replayed 13 actual distinct tool-call records through the installed generated bridge in a JavaScript VM with a mocked socket, then through the exact installed CircuitBreaker implementation:
Suggested fix
Use ev.toolName for the tool name on both events and include ev.input as tool_input on PostToolUse. Preserve the breaker threshold and behavior.
Fix the PI_EXTENSION generator as well as regenerated bridges: installPiHooks rewrites each agent's bridge during startup. Add regression coverage for varied Pi tool calls and true repeated calls. Existing sessions also need the corrected bridge loaded and stale breaker state cleared or recovered.
This is a confirmed local diagnosis and isolated proposed-fix replay. No production/app patch has been installed yet.