Best possible solution:

Land one canonical implementation for #97761, preferably the proof-positive narrow candidate in #97769 unless maintainers choose the broader alternative, then close the remaining duplicate branches.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection shows current main does not transform ToolCall.arguments in the final message path, while agent-loop executes tool calls from response.result(); I did not run a live DeepSeek/chat-space scenario in this read-only review.

Is this the best way to solve the issue?

No. This PR is a plausible partial fix, but the best fix must also transform final assistant-message ToolCall.arguments; #97769 already does that with real behavior proof.

Security review:

Security review cleared: The diff only changes the agent text-transform helper and its focused test; no dependency, CI, permission, package, downloaded-code, or secret-handling surface changed.

AGENTS.md: found and applied where relevant.

What I checked:

• Root and scoped policy read: Root AGENTS.md and scoped src/agents/AGENTS.md were read fully; the review applied the required whole-path and best-fix checks for agent runtime changes. (AGENTS.md:1, 6cb82eaab865)
• Current transform gap on main: Current main transforms text content and nested content, but transformContentText has no branch for { type: "toolCall" } or arguments, so final assistant messages can keep masked tool-call arguments. (src/agents/plugin-text-transforms.ts:48, 6cb82eaab865)
• Final message drives execution: The agent loop takes await response.result() as the final assistant message, and tool execution is derived from assistantMessage.content.filter((c) => c.type === "toolCall"), so result-path tool-call arguments matter for execution. (packages/agent-core/src/agent-loop.ts:519, 6cb82eaab865)
• Tool-call event contract: The stream contract uses toolcall_delta.delta and toolcall_end.toolCall, and ToolCall.arguments is structured as Record<string, unknown>. (packages/llm-core/src/types.ts:250, 6cb82eaab865)
• This PR remains partial: At this PR head, the new branches cover toolcall_delta and toolcall_end.toolCall, but stream.result() still calls transformMessageText, whose content transform still lacks tool-call argument handling. (src/agents/plugin-text-transforms.ts:149, dce7b8617c4c)
• Superseding PR covers all paths: fix(plugins): apply output text transforms to toolcall_delta and toolcall_end events #97769 is open, mergeable, labeled proof-sufficient, preserves tool names, adds ToolCall.arguments handling in transformContentText, and its test asserts the stream.result() tool-call block is transformed. (src/agents/plugin-text-transforms.ts:65, ff462d3dc209)

Likely related people:

• steipete: git show ties Peter Steinberger to feat: add plugin text transforms, which added the helper and tests now being changed, and history also shows adjacent stream-wrapper work. (role: introduced behavior and adjacent owner; confidence: high; commits: 202f80792ed1, 4e2541e5fbbf; files: src/agents/plugin-text-transforms.ts, src/agents/plugin-text-transforms.test.ts, src/plugins/provider-runtime.ts)
• vincentkoc: Recent history shows adjacent provider/plugin runtime seam work that the text-transform wrapper depends on, including provider runtime and embedded runner paths. (role: recent adjacent contributor; confidence: medium; commits: a7436c8b4a93, 7198a9f0eeed; files: src/plugins/provider-runtime.ts, src/agents/embedded-agent-runner/run/attempt.ts, src/agents/cli-backends.ts)
• pick-cat: Current git blame attributes the inspected transform and agent-loop lines to a recent commit, but that commit appears broad/adjacent rather than the feature introduction, so this is only a weak routing signal. (role: current-line provenance; confidence: low; commits: eb5fb2aa69f4; files: src/agents/plugin-text-transforms.ts, packages/agent-core/src/agent-loop.ts)

Codex review notes: model internal, reasoning high; reviewed against 6cb82eaab865.