[Bug] Cold history resolves the wrong presenter for agent-scoped shadow tools

[Jstn-1g]

Summary

A tool registered on a live agent scope may legitimately shadow a same-name tool from its preset. Live presentation resolves through the agent and uses the definition that actually executed. After that agent is gone, session.history resolves presenters through the recorded preset's standing key instead. The former agent layer is absent, so a same-name preset definition wins—even though it did not execute the logged call.

When the two definitions have different argument schemas, the standing definition's defineTool wrapper soft-rejects the logged arguments before its presenter runs. The result falls back to a generic card. Persisted presentationMeta cannot help because the registry chooses the wrong definition first.

This means a scoped shadow tool can render correctly live but lose its result card after restart/cold history.

Concrete downstream case

dsh-better-edit issue #25 asks why its hash-anchored edit results never render as diff cards.

The plugin is mounted on the host plane and, at agent/session-start, registers its edit on agent.ctx, intentionally shadowing the preset's built-in edit (install, registration). Its arguments are { path, edits }; the built-in edit expects { file_path, old_string, new_string }.

I implemented the apparent fix locally: structured canonical output carrying diff data, output.presentationMeta, defensive metadata narrowing, and presentResult. Live presentation and JSON-round-tripped metadata worked, and 679 tests passed. A separate registry/history review found the cold-path failure, so I did not publish that patch as a PR.

Cold replay does this:

1. Resolve edit at the preset standing key.
2. Select the built-in edit, because the agent-local shadow no longer exists in that view.
3. Soft-validate the persisted { path, edits } against the built-in schema.
4. Return no view and render the generic result card.

The correct diff metadata is present but never reaches the presenter that understands it.

Source path

Current master inspected at b150a551b8d465e31e418e1b2eaf5e79bbb7d28e:

• ToolRuntime.register() stores the whole definition in the caller's layer; same-layer duplicates fail.
• ToolRuntime.get(name, scope) returns the nearest visible same-name definition.
• viewFor() selects that definition by logged name before invoking presentCall / presentResult.
• A cold session deliberately uses agentPresets.standingKeyFor(...), without resuming an agent.

The individual pieces are internally consistent, but the log stores only the tool name/arguments/result metadata—not the identity of the scoped definition/presenter that produced them.

Why the plugin cannot repair this cleanly

• A global edit presenter/definition loses to the preset's nearer built-in edit.
• Registering another edit in the standing layer collides with the built-in definition.
• A child/agent registration is unavailable once cold history has no agent.
• A distinct tool name avoids the collision but changes the plugin's public tool contract.
• Resuming an agent only to render history would add side effects and defeat the cold-history design.

There is currently no presenter-only registry or supported arbitrary-scope presentation overlay.

Minimal regression

1. Register built-in edit on a preset standing scope.
2. Register a different edit definition on a child live-agent scope, with incompatible arguments and a diff presenter.
3. Execute/log the child definition and persist its presentation metadata.
4. Assert live presentation returns card: "diff".
5. Remove the live agent and request sessions.history for the same log.
6. Current result: the standing built-in definition returns no view.
7. Desired result: cold history still resolves the presenter that produced the logged metadata and returns the diff card.

A sibling preset that never installed the shadow should continue resolving the official edit presenter.

Possible provider-neutral seams

Either of these would make the invariant representable without restoring execution authority:

1. A durable presentationKey/definition identity recorded with tool events plus a separate registry of pure presenters. Cold history resolves by that key; unknown or obsolete keys fall back generically.
2. Persist a validated, JSON-only ToolEventView at execution time and let history replay it after validating the view schema.

The first keeps current presenters reusable and versionable; the second makes historical rendering independent of current composition. In either design, the presentation identity must not grant tool execution, metadata remains untrusted/validated, and failure should retain today's generic fallback.

Environment

• Reproduced against published 0.1.0-rc.6 contracts.
• Re-audited on master b150a551b8d465e31e418e1b2eaf5e79bbb7d28e.
• Windows 11 / Node 24; the failure is scope/log topology, not platform-specific.

[Jstn-1g]

I added a runnable, test-only reproduction pinned to Harness b150a551:

Jstn-1g@cdc8f54d4

It mounts real ToolRuntime layers with a standing built-in edit and an incompatible agent-scoped shadow edit, records one call/result pair, proves the live history renders the shadow diff, disposes the agent scope, and then requests the same history through the cold presenter path.

pnpm exec vitest run packages/host/apiproxy/tests/api-proxy-view.spec.ts -t 'Discussion #4166' --reporter=verbose

The current expected result is one passing control and one explicit failing regression: the cold view is undefined, while the live view is the full diff card. The host aggregate typecheck, workspace constraints, repository pre-commit/pre-push checks, and git diff --check all pass; no production code is changed.

I’m leaving this as a reference-only branch rather than opening an external PR. Happy to adapt the regression around whichever provider-neutral fix maintainers prefer.

[freeskyflying]

orry, I made a mistake. My tests were actually built from the latest Harness repository, and the correct version is dsh-0.1.1-rc.2 (commit b150a55).

[Jstn-1g]

Thanks for confirming that the reproduction target was dsh-0.1.1-rc.2 at b150a55. I built a reviewable reference implementation against that exact revision:

• Reference branch: https://github.com/Jstn-1g/deepseek-harness/tree/reference/discussion-4166-durable-presenter-id
• Final commit: Jstn-1g@aaf722f

The implementation adds an opt-in durable presenter identity:

• ToolPresenterId identifies pure presenters in a process-global, lifecycle-owned registry. defineToolPresenter() provides typed callbacks with soft validation for older logged arguments.
• Before appending tool/call, the scheduler synchronously captures the exact visible ToolDefinition object and its presenter ID. If an observer, awaited policy hook, disposal, or HMR replacement changes that definition before a definition-dependent stage, the call fails closed as UNKNOWN_TOOL. A same-named replacement—even one using the same presenter ID—cannot execute or normalize output under the captured identity. Existing denial/cancellation precedence is preserved, and the captured definition's finalizer still owns last-mile error shaping.
• tool/call stores the selected presenter ID; tool/result remains paired through callId.
• Live and cold ApiProxy replay resolve keyed calls only through that exact ID. If it is unavailable, replay uses generic presentation and never borrows same-name UI. Older unkeyed records retain the existing scope/name behavior.

Compatibility:

• Opt-in; no shipped tool opts in, so default model-visible schemas and generated Code Mode SDKs are unchanged.
• Uses existing event-data JSON; no SQLite migration.
• SESSION_FORMAT_VERSION remains 0 under the repository's explicit prerelease policy. The Agent Note records that a post-v0 change would require a format bump.
• Stable presenter IDs version argument/view semantics.

Verification on the exact tree:

• 395/395 core tools tests
• 201/201 focused registry, scheduler, agent-loop, and ApiProxy tests
• Full host + client pnpm run typecheck
• Doc-sync 28/28 and 1,004 bilingual pairs
• Keyed Python SDK fixture and TypeScript JSON-RPC snapshots included
• git diff --check

Since the upstream contribution route does not accept external PRs, this is a reference branch/commit for maintainers to review, adapt, or lift. Happy to revise it around maintainer feedback.