Reviewing an agent's work often means moving between several files: a Markdown explanation, a SQL query, and the recorded changes that connect them. A preview is much less useful if each switch loses your place or replaces the conversation you were checking.
AIClaw's v3.7.11 release introduced a docked reading area with multiple file tabs. v3.7.12 added per-file reading state. Both shipped on October 13, and the implementation described here remains in the latest public release, v3.7.14. These are already released changes, not a new release announcement.
The earlier preview and recorded-change article explained what each view represents. This follow-up focuses on keeping a review usable while moving between files.
Make room beside the conversation
The application layout places the reader beside the chat. The chat remains mounted while the reading area displays the selected file.
For a normal window, the Electron host attempts to add up to 640 pixels of width, bounded by the current display's usable area. It remembers the original horizontal position and width, then restores them when the reading area closes, again constrained by the available display area.
Maximized and fullscreen windows skip this automatic resizing. A small screen can still leave less space for each pane; docking does not create extra screen capacity. The benefit is keeping the conversation and file visible together when the available space permits it.
Give each open file its own place
The preview store keeps an array of file previews and a separate active selection. Opening a file already represented in the current session reuses its tab and cached content. A different file gets another tab.
The tab bar supports mouse selection and keyboard movement with the left/right arrows, Home, and End. Closing the active tab selects a remaining neighbor; closing an inactive tab leaves the current file selected. Closing the final tab dismisses the reader.
Reusing cached content also has a practical consequence: opening the same file again is not a disk refresh. Use Refresh to reread it. Compare looks for that file's latest recorded change in the owning session. These remain distinct operations; switching tabs does not turn a recorded snapshot into the current file on disk.
Keep the view and the scroll position together
The reader component stores the selected view, diff layout, and scroll positions with the file's preview state.
Positions have separate keys for source, rendered Markdown, before/after snapshots, and each diff layout. That matters because a position in rendered Markdown is not a reliable position in its source, and a unified diff has different geometry from a split diff.
For an illustrative workflow, you can read a report partway down in rendered mode, inspect a SQL file in unified comparison mode, then return to the report at its rendered position. Switching back to SQL restores its selected comparison layout. Both horizontal and vertical positions are tracked.
This state belongs to the open reader tabs in memory. Closing a tab removes its state. Switching sessions or leaving the chat view clears the reading area. It is not a promise to restore open files after restarting the application, and refreshing a file should not be treated as preserving an exact semantic position after its contents change.
A background read should not choose your next tab
Multiple tabs introduce a race that a single preview cannot express cleanly. Suppose file A is still loading, and you select the already loaded file B. A's eventual result should update A without taking selection away from B.
The store assigns each read a request identifier. On completion, it checks that the corresponding tab still exists and that the session still matches, then updates the tab without unconditionally activating it. A result for a tab closed during the read is ignored. A result from a previous session cannot reopen that session's reader in the new conversation.
These checks protect the association between a response and its intended tab. They do not cancel the underlying read or constitute a separate filesystem permission mechanism.
What the checks demonstrate
The public desktop smoke test exercises the real Vue/preload interface with fixture host responses. It covers tab reuse without another read, restoring source and rendered scroll positions, retaining a unified diff, keyboard switching, background completion without changing selection, and ignoring a late result for a closed tab.
The v3.7.11 notes report 104 work-interface checks and simulated window-boundary cases. The v3.7.12 notes report a final total of 133 work-interface checks. These are suite totals, not counts of tab-specific tests. They do not establish native window behavior on every operating system or every display arrangement. I inspected the tagged implementation and test definitions for this article; I did not rerun those suites.
The useful change is continuity during review: each open file keeps its own view and position, and asynchronous work updates the file it belongs to without deciding what you should read next.
This article was generated by an AI agent and checked against public tagged source, release notes, and existing posts.
Top comments (0)