Skip to content

[Feature]: Surface Claude Edit/Write before/after text in expanded tool entries #10970

Description

@IcTxDiogo

Summary

Expanded tool entries for Claude Edit/Write calls show file paths but never the changed text — no before/after and no diff. Codex turns already surface unifiedDiff data; the Claude path has no equivalent, so reviewing what an edit actually changed requires leaving T3 or re-reading the file.

Current behavior

  • For Claude edits, the expanded entry carries paths/summaries only. The tool input text (old_string/new_string/content) never reaches the UI in any form.
  • Checked on stable 0.0.40 and on current main: a code search shows no old_string/new_string/unifiedDiff handling in ClaudeAdapter.ts — unifiedDiff exists only around the Codex/checkpoint paths, which is a different mechanism (turn-level summaries, not per-edit before/after).

Expected behavior

  • Expanded Edit/Write entries include a bounded verbatim before/after pair (with a truncation flag when the bound is hit), rendered in the existing expandable work-log row — no new UI surface needed.
  • Collapsed rows stay exactly as today.

Repro

  1. In a Claude-backed thread, ask the agent to edit any tracked file.
  2. Expand the Edit/Write work-log entry.
  3. The entry shows paths only; the old/new text is nowhere in the UI although it was present in the tool input.

A per-field bound keeps this consistent with the recent payload-slimming direction. Happy to provide fixtures or help validate a bounded-payload design.

Activity

  1. juliusmarminge commented on Sep 9, 2026

    @juliusmarminge
    Member

    Triage

    Confirmed on current main. Claude Edit/Write expanded work-log rows show paths/summaries only; the tool input text never appears as a reviewable before/after.

    This is not a duplicate of #6388 (Bash output never renders). Same general “persisted tool payload doesn’t reach the expanded row” shape, different field and UI.

    What the code does today

    ClaudeAdapter already attaches the full tool input on item.started / item.updated / item.completed:

    data: { toolName, input } // input has file_path, old_string, new_string, content

    There is no Claude unifiedDiff / before-after mapping. Codex unifiedDiff is turn-level (turn.diff.updated → checkpoint placeholders), not per-edit.

    The drop happens in projectActivityPayload (ActivityPayloadProjection.ts). For non-MCP tools it keeps toolName and path-like keys as data.files, and drops data.input. item.completed still persists the full payload; the wire snapshot does not.

    The UI would not show it even if it survived: web (session-logic.ts + MessagesTimeline.tsx) and mobile (threadActivity.ts) only attach toolData for mcp_tool_call. Expanded file-change rows render command / detail / changedFiles. detail is a ~180-char JSON dump of the input, so it is a path prefix, not a before/after pair.

    collectChangedFiles also misses Claude’s snake_case file_path (path / filePath only), so paths often survive only via that truncated detail.

    Not already in flight

    No open PR implements this. Related but not a fix: #7184 (Bash output), #5482 (payload slimming), #9549 (expanded-row cleanup). Closed #5471 (rich transcript / inline diffs) is not a leftover close.

    Suggested fix

    Treat this as an accepted enhancement. Keep collapsed rows as they are. On expand, show a bounded verbatim before/after (plus a truncation flag) in the existing work-log row — no new surface, no Codex unifiedDiff reuse.

    1. Slim file_change input to bounded old_string / new_string / content (and collect file_path).
    2. Render that pair in the existing expanded body on web and mobile.
    3. Add projection + UI fixtures. Happy to use reporter-provided fixtures for the bound.

    Severity: medium UX gap. Type: enhancement.

  2. added
    enhancementRequested improvement or new capability.
    acceptedfeature request accepted
    via-triageFiled through npx t3 triage
    on Sep 9, 2026
  3. locked and limited conversation to collaborators on Oct 11, 2026
  4. converted this issue into a discussion #17976 on Oct 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    acceptedfeature request acceptedenhancementRequested improvement or new capability.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions