Skip to content

Pi bridge drops tool name/input, causing false circuit-breaker constraints #502

Description

@coreyallen

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

  1. Launch a Pi agent in Munder with working credentials and the default eight-call repetition threshold.
  2. Have it perform at least eight different successful tool calls, such as reading different files and running different commands.
  3. Let the breaker evaluate on successive heartbeat ticks.
  4. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions