Pi adapter does not enforce mandatory context-mode routing for read-only tools

Summary

The Pi adapter injects context-mode routing guidance, and the bundled skills/context-mode/SKILL.md describes that routing as mandatory:

Default to context-mode for ALL commands. Only use Bash for guaranteed-small-output operations.

However, the Pi extension only hard-blocks a narrow set of HTTP patterns inside bash (curl, wget, inline fetch, etc.). Ordinary read-only bash commands, read, and other potentially high-output tools remain unrestricted, so the model can bypass ctx_execute, ctx_execute_file, and ctx_batch_execute despite the mandatory wording.

This makes context-mode usage advisory rather than enforced on Pi. In practice, a task can complete primarily through raw tools while ctx_stats reports no token savings.

Environment

• Platform: Pi
• context-mode: 1.0.169
• OS: macOS
• Install: Pi npm package

Steps to reproduce

1. Install and enable context-mode in Pi.
2. Start a fresh Pi session.
3. Ask the agent to inspect dependencies, analyze files, run commands, or research a package.
4. Observe that the agent may use ordinary read/bash or other raw-output tools instead of ctx_execute_file/ctx_execute.
5. Run ctx_stats; tool usage and token savings may remain zero even though the task involved read-only inspection.

The MCP bridge itself is healthy and all ctx_* tools are callable. This is a routing/enforcement issue, not tool registration failure.

Current implementation

In build/adapters/pi/extension.js, the tool_call handler returns early for every tool except bash:

const toolName = String(event?.toolName ?? "").toLowerCase();
if (toolName !== "bash") return;

For Bash, it only blocks language-level HTTP clients and unsafe curl/wget invocations. It does not enforce the broader policy from SKILL.md.

The per-turn injection is also deliberately lightweight:

context-mode active. Hierarchy: ctx_batch_execute > ctx_execute > ctx_execute_file > ctx_search.

That instruction can influence the model, but does not guarantee routing.

Expected behavior

Either:

1. Provide an optional strict mode for Pi that intercepts read-only/high-output tools and redirects or blocks them with guidance to use the appropriate ctx_* tool; or
2. Change the Pi-facing documentation from “mandatory” to “advisory/best effort” and document that only unsafe HTTP output is currently enforced.

A strict implementation should preserve direct mutation tools (edit/write), exact reads required for editing, and host/project-mandated semantic tools. It should also retain the MCP-down escape hatch introduced by #625.

Related issues

• #426 fixed missing Pi MCP tool registration.
• #477 notes that E2E coverage must verify whether the real LLM chooses ctx_* tools.
• #529 discusses PreToolUse routing for external MCP tools and notes Pi is bridge-mediated.
• #625 covers Pi's narrow HTTP enforcement and recovery escape hatch.
• #1021 confirms Pi exposes the hooks needed for full interception.

I could not find an existing issue specifically covering the mismatch between Pi's mandatory routing documentation and its current enforcement scope.

Start in build/adapters/pi/extension.js at the tool_call handler, then compare its enforcement with skills/context-mode/SKILL.md and the MCP-down escape hatch from #625. Review the hook behavior described in #1021 and determine whether strict routing or documentation changes are in scope. Done means the mandatory wording matches behavior, while preserving edit/write, exact reads, semantic tools, and recovery behavior.