Pi: suppress unchanged pre-tool plan injections, matching Claude Code’s #312 behavior #323

Summary

Could the unchanged-view suppression introduced for Claude Code in #312
(v3.24.0) also be applied to the Pi extension?

Pi currently deduplicates queued pre-tool messages by session leaf ID,
rather than by the content of the injected plan view. As the session
advances, an unchanged plan can therefore be injected repeatedly.

Environment

• planning-with-files: 3.24.0
• Host: Pi Coding Agent
• Plan hooks activated through /plan-execute
• Observed messages include PreToolUse recitation and ACTIVE PLAN

Current behavior

In extensions/planning-with-files/runtime.ts, the tool_call handler
uses preToolQueuedByLeaf with a key based on:

sessionId + leafId

This prevents repeated queuing at the same session leaf, but does not
remember whether the session has already received the same plan content.

When the leaf changes during subsequent tool execution, the same
unchanged plan view can be queued again.

Observed impact

I inspected the 20 most recently updated local Pi session files.
Two contained plan-body injections:

Of the 139 injections:

• 128 were pre-tool recitations.
• 11 were agent-start plan/progress injections.
• 118 messages were byte-for-byte identical to a previously injected
  message in the same session.

The exact-repeat count compares entire injected messages, not just
similar plan sections. Attestation warnings and compaction reminders
were excluded.

These are counts from stored session records, not measurements of the
final provider request payload or attributable billing. The sessions
also used Observational Memory and compaction, so I am not treating
historical message volume as an exact API token-cost estimate.

Nevertheless, repeatedly appending unchanged plan text creates
avoidable context volume and potentially increases cumulative input
usage when those messages remain in subsequent requests.

This is not a claim that appending a message invalidates the existing
prompt cache. As discussed in #210 and #312, the concern is additional
prefix length carried by later requests.

Suggested behavior

Please port the semantics of #312 to the Pi extension:

1. Keep the normal agent-start plan injection.
2. Record the corresponding pre-tool view as already supplied.
3. Suppress subsequent pre-tool injections while that view is unchanged.
4. Refresh once when the visible plan view changes.
5. Reset or invalidate the state appropriately after recovery,
   compaction, or a plan switch.
6. Keep state isolated by session and selected plan.
7. Continue running plan-selection and attestation checks before
   deciding whether to suppress an injection.

An explicit override to retain per-call recitation, equivalent to
PWF_PRETOOL=always, could preserve the existing behavior for users
who need it.

This request is specifically about redundant pre-tool injections.
It does not propose removing turn-start recovery context or introducing
a new periodic-injection policy.

Acceptance criteria

• An unchanged plan produces no additional pre-tool plan messages
  after the initial plan context has been supplied.
• A visible-view change causes one refresh, not repeated refreshes
  on every subsequent tool call.
• Recovery and compaction allow the plan context to be supplied again.
• Switching plans does not incorrectly suppress the newly selected plan.
• Independent sessions do not suppress each other’s injections.
• Attestation failures remain visible and are not hidden by deduplication.
• Tests cover unchanged views, changed views, session isolation,
  plan switching, and recovery/compaction resets.

Related

• Claude Code: PreToolUse re-injects the unchanged plan head before every Read/Bash/Grep/Glob/Write/Edit call #312 — unchanged PreToolUse view suppression for Claude Code
• Does this break prompt caching? #210 — prompt caching and cumulative prefix-length costs

I would be happy to contribute a focused PR with regression tests if
this direction is welcome.