renderCall/renderResult overrides silently ignored for built-in tools since v0.62.0

[zshuzh]

What happened?

Since v0.62.0, registering a custom renderCall/renderResult for a built-in tool (via pi.registerTool with the same name) has no effect. This breaks the minimal-mode example extension.

Cause

The v0.62.0 rewrite of tool-execution.ts replaced shouldUseBuiltInRenderer() check with
isBuiltInDefinition():

  // v0.62.0 — broken
  isBuiltInDefinition(definition) {
      return (
          this.builtInToolDefinition !== undefined &&
          definition.parameters === this.builtInToolDefinition.parameters  // reference equality
      );
  }

  // Then:
  if (!this.toolDefinition || this.isBuiltInDefinition(this.toolDefinition)) {
      return this.builtInToolDefinition.renderResult;  // extension's renderResult ignored!
  }

Because all built-in tool definitions return the same module-level parameter schema singleton (e.g. readSchema), any extension that borrows the parameters via createReadTool().parameters or createReadToolDefinition().parameters will match this check and have its renderers silently ignored.

The pre-v0.62.0 implementation handled this correctly:

  // Pre-v0.62.0 — correct
  private shouldUseBuiltInRenderer(): boolean {
      const isBuiltInName = this.toolName in allTools;
      const hasCustomRenderers = this.toolDefinition?.renderCall || this.toolDefinition?.renderResult;
      return isBuiltInName && !hasCustomRenderers;  // checks actual renderer presence, not parameter identity
  }

Workaround

I've managed to work around this by modifying the minimal-mode extension to fail the reference equality check by spreading the borrowed parameters into a new object. For example:

parameters: createReadTool(cwd).parameters // doesn't work
parameters: { ...createReadTool(cwd).parameters } // works

The fact that this works also suggests that the hypothesis above is correct.

Steps to reproduce

You can observe this by trying to use the example minimal-mode extension which does not work anymore, which is how I initially discovered the issue.

Expected behavior

The minimal-mode extension should let you cycle to a minimal view mode with Ctrl-O.

Version

0.62.0

[github-actions]

Hi @zshuzh, thanks for opening an issue.

OSS weekend is active until Monday, March 30, 2026, so new issues are being auto-closed for now.

Please reopen or submit this issue again after Monday, March 30, 2026. For support, join Discord.

[badlogic]

Fixed on main.

Root cause was renderer selection in ToolExecutionComponent treating any built-in override that reused a built-in parameter schema singleton as if it were still the built-in definition. That bypassed extension renderCall and renderResult handlers, which is why minimal-mode stopped working.

The fix removes that parameter-identity check and does renderer fallback slot-by-slot:

• use the extension renderer when that slot is provided
• otherwise fall back to the built-in renderer

Also added regression coverage for overrides reusing parameters from both createReadToolDefinition() and createReadTool().