harness-pi: tools registered by extensionFactories extensions never reach the model (dropped by `tools` allowlist)

[hteek]

Description

@ai-sdk/harness-pi 1.0.101. PiHarnessSettings.extensionFactories loads inline pi extensions, but any tool such an extension registers via pi.registerTool() is invisible to the model.

Cause, in createPiSession → rebuildPiSession:

const { session } = await createAgentSession({
  ...
  customTools,
  ...hasMcpServers ? { noTools: "builtin" } : { tools: toolNames },

tools: toolNames (the 7 harness builtins + host tools) becomes pi's allowedToolNames; AgentSession._refreshToolRegistry filters extensionRunner.getAllRegisteredTools() through it, so extension tools are removed. Only when mcpServers is set does the harness use noTools: "builtin", which is the mode pi documents as "keeping extension and custom tools enabled".

Reproduction

createPi({
  model, auth,
  extensionFactories: [async (pi) => {
    pi.registerTool({ name: 'ping', label: 'ping', description: 'ping', parameters: Type.Object({}), execute: async () => ({ content: [{ type: 'text', text: 'pong' }] }) });
  }],
});
// prompt: "list your tools" → read, write, edit, bash, grep, find, ls  (no `ping`)

Same with a real-world extension (context-mode's pi adapter, which registers ctx_* tools).

Fix that works for us

-      ...hasMcpServers ? { noTools: "builtin" } : { tools: toolNames },
+      ...hasMcpServers || hasExtensionFactories ? { noTools: "builtin" } : { tools: toolNames },

Applied as a pnpm patch; with it the model sees builtins + extension tools and extension tool calls round-trip correctly. If extension-registered tools are intentionally unsupported, the extensionFactories docs should say so.

[ai-sdk-factory]

Identify issue type

Identified as Bug
Confidence: High

Rationale

This is a concrete failure of the existing extension registration behavior: extensions load and register tools, but those tools are unexpectedly filtered out before reaching the model.

Evidence

• Tools registered through extensionFactories using pi.registerTool() are omitted from the model-visible tool list.
• The report identifies tools: toolNames as an allowlist that filters out extension-registered tools.
• A concrete reproduction on @ai-sdk/harness-pi 1.0.101 shows the built-in tools but not the registered ping tool.

[ai-sdk-factory]

Bug Reproduction - AI SDK 7

Bug was reproduced.

Branch: main
PR: successful reproduction pull request

Details

• The expected behavior is for the ping tool registered through extensionFactories to be included in the provider request so the model can discover and call it.
• packages/harness-pi/src/pi-session.ts passes tools: toolNames when MCP is absent; the captured request contained only read, write, edit, bash, grep, find, and ls, dropping ping.
• examples/ai-functions/src/reproduction/issue-20402.ts captures the actual provider request and exits 1 because ping is absent instead of model-visible.
• The failure remains on checked-out @ai-sdk/harness-pi 1.0.104, so upgrading from the reported 1.0.101 to this target does not resolve it.
• A diagnostic change using hasMcpServers || hasExtensionFactories made the same reproduction include ping and exit successfully; the product-code change was reverted.

Relevant Documentation

• https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/sdk.md
• https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/extensions.md

[ai-sdk-factory]

Bugfix - AI SDK 7

Created bugfix and opened PR: #20404

Root Cause

createPiSession passed tools: toolNames whenever MCP was absent, creating Pi's global tool allowlist without extension-registered names. The reproduction confirmed only the seven harness tools reached the provider, and Pi's implementation confirmed the allowlist filters extension tools.

Summary

Pi sessions with extension factories now use noTools: "builtin", preserving harness custom tools while allowing extension-registered tools. Added a patch changeset and removed reproduction-only artifacts.

Testing

Added regression coverage verifying inline extension sessions avoid the restrictive tools allowlist and retain extension tools.