Read what a session changed on disk
The files this session’s write, edit and delete tools changed, each with what it did to the file, how many lines moved, and the content the file held before the session first touched it. It is what a diff view of a session’s own work stands on, and what a touched-files list shows counts from. Every row is measured from FIRST touch. A file the session edited five times is one row comparing what it held before edit one against what is on disk now — not five rows, and not the last edit’s delta. That is also why a file put back the way it was is absent from the answer: it changed nothing, and reporting it at zero lines either way would claim otherwise. The current content is deliberately not served. The host and its clients share a filesystem, so a client reads the file itself and gets the version it is about to let somebody edit, rather than a copy that was already stale when it was sent. What only the host has is the before side. Both sides are bounded at 1 MiB (1048576 bytes). Past that nothing was kept, and the row says so through beforeState rather than serving an empty file or a truncated one: beforeBytes still carries the real size, so a client can say how large the file it cannot diff is. linesAdded and linesRemoved are then absent, because a count nobody could compute is not zero.
Path Parameters
The session's id.
Query Parameters
Filter to one file, by the absolute path this operation reports for it, and serve that file's before content. Without it the answer covers every file the session changed and carries no content at all — a change list stays cheap, and the one file a diff view is opening is the one it asks for. A path this session never changed is an empty answer, not an error.
4096Answer for ONE step of the conversation instead of for the session: what the tool call recorded on this entry did to each file it mutated, measured from the restore point taken before that entry to the one taken at it. Both sides are then served (beforeContent and afterContent), because the after side is a moment that has since been edited over and nothing on disk remembers it. It exists because the session-scoped answer above is the wrong one under an old receipt: a file edited five times has one row carrying all five edits, so drawing it under the first receipt credits that call with every line that came after it. An entry whose step mutated nothing is an empty answer, not an error, and a step the host never snapshotted comes back with beforeState "too-large" — nothing was kept — rather than as an empty diff. path and entryId are not combined; entryId wins when both are given.
Response
The files this session changed.
Every file a session changed, in the order the session first met them. Not paginated: the set is bounded by what one conversation's tools actually mutated, and a client that wants one file asks for it by path.