# AIClaw's Docked Reader Adds Per-File Tabs and Scroll Memory to Agent Reviews

A community write-up describes how the desktop tool's v3.7.11 and v3.7.12 releases keep each reviewed file's view, diff layout and scroll position in its own tab, and how background reads avoid stealing the active selection.

Canonical URL: https://freelancenews.online/news/aiclaw-s-docked-reader-adds-per-file-tabs-and-scroll-memory-to-agent-1686852e
Published: 2026-10-16T01:17:50.416Z
Updated: 2026-10-16T01:17:50.416Z
Source published: 2026-10-15T23:59:54.000Z
Event date: 2025-10-13
Review status: source-reviewed
Review method: Automated comparison against retrieved source text; not independent fact-checking.

## Report

A community post on dev.to describes a set of already-shipped changes to AIClaw, a desktop application for reviewing an agent's work, that give each open file its own tab in a reading area docked beside the chat. The author states that v3.7.11 introduced the docked reading area with multiple file tabs and that v3.7.12 added per-file reading state, with both shipping on October 13. The same author says the implementation described remains in the latest public release, v3.7.14, and frames the piece explicitly as a follow-up to an earlier article about what each view represents rather than as a new release announcement.

Because the account comes from a community post rather than vendor documentation, the specifics below should be read as the author's description of tagged source and release notes they say they inspected. The author states they did not rerun the test suites, which is a meaningful caveat for anyone weighing the claims about reliability.

The layout change is the starting point. The reader sits beside the conversation, and the chat stays mounted while the reading area shows the selected file. In a normal window, the author writes, the Electron host tries to add up to 640 pixels of width, bounded by the usable area of the current display. The application remembers the original horizontal position and width and restores them when the reading area closes, again constrained by available display space. Maximized and fullscreen windows skip this automatic resizing, and the author notes plainly that docking does not create extra screen capacity on a small display; the benefit is keeping conversation and file visible together only when space permits.

The second piece is the tab model. File previews are held in an array by the preview store, alongside an active selection kept separately. When a file is opened that the current session already represents, its tab and cached content are reused; a different file, by contrast, receives another tab. Mouse selection is supported by the tab bar, as is keyboard movement via the left and right arrows, Home and End. Should the active tab be closed, a remaining neighbor is selected; if an inactive tab is closed, the current file stays selected; and once the final tab is closed, the reader is dismissed.

One consequence the author flags is that reusing cached content means reopening the same file is not a disk refresh; a separate Refresh action rereads it. The author also distinguishes comparing a file's latest recorded change in the owning session from reading the current file on disk, and states that switching tabs does not turn a recorded snapshot into the live file.

The third piece concerns itself with preserving where you were. Selected view, diff layout and scroll positions are stored by the reader component for each file's preview state. Separate keys are used for positions across source, rendered Markdown, before/after snapshots and each diff layout. Why? The author reasons that a position in rendered Markdown cannot be relied on as a position in its source, and that a unified diff's geometry differs from a split diff's. An illustrative workflow is offered by the author: reading a report partway down in rendered mode, inspecting a SQL file in unified comparison mode, then returning to the report at its rendered position, with the SQL file restoring its comparison layout when you switch back. Both horizontal and vertical positions are tracked.

The limits of that state are stated as clearly as the capability. It belongs, in memory, to the open reader tabs; when a tab is closed, its state is removed; and the reading area is cleared by switching sessions or leaving the chat view. The author says this is not a promise to restore open files after an application restart, and that treating a refresh of a file as preserving an exact semantic position after its contents change should not be done.

A concurrency issue that a single-pane preview cannot cleanly represent is the subject of the fourth piece. The scenario the author gives: while one file is still loading, the user selects a second file that has already finished loading. That first file's tab ought to be refreshed by the pending result, and the user's selection ought not to be moved off the second file. Every read is tagged with a request identifier by the store, the author says, to handle this. Upon a read completing, the store checks that the tab it belongs to is still present and that the session still matches, then refreshes that tab without forcing it to become the active one. A result arriving for a tab that was closed mid-read is discarded, and a result left over from an earlier session cannot cause that session's reader to reappear in the current conversation. The author is careful to say that what these checks safeguard is the link between a response and the tab it was meant for; the underlying read is not cancelled by them and they are not a separate filesystem permission mechanism.

On verification, a public desktop smoke test is pointed to by the author that exercises the real Vue and preload interface with fixture host responses. The author lists what it covers: a tab being reused rather than triggering a second read, source and rendered scroll positions coming back correctly, a unified diff being retained, keyboard switching, a background completion that leaves the selection untouched, and a late result for a closed tab being ignored. The v3.7.11 notes are said to report 104 work-interface checks and simulated window-boundary cases, and the v3.7.12 notes a final total of 133 work-interface checks. The author stresses that these are suite totals, not counts of tab-specific tests, and that native window behavior on every operating system or every display arrangement is not established by them.

That distinction matters for how this should be read. A passing suite total is not evidence that docking behaves identically across window managers, multi-monitor setups or unusual display scaling, and the author does not claim it is. The window-boundary cases are described as simulated, which is a different kind of evidence from testing on real hardware.

For freelancers and developers who review agent output, the practical value described here is continuity rather than new capability. If the account is accurate, a reviewer moving between a Markdown explanation, a SQL query and the recorded changes connecting them can keep each file's view mode, diff layout and scroll position, and a slow background read will not yank the interface to a different file. That is the kind of friction that tends to matter on long review passes, where losing your place repeatedly is the cost.

The tradeoffs are also worth naming. The docked reader consumes horizontal space and the author is explicit that it does not manufacture room on a small screen. Cached tab content means reopening a file is not a fresh read, so anyone expecting the tab to reflect on-disk changes needs the separate Refresh action. And the reading state is in-memory only, so it does not survive a restart or a session switch.

What remains unknown from this evidence is substantial. There is no pricing or availability information for the application, no independent confirmation of the release notes or test totals, and no detail on which operating systems or display configurations were exercised. The author inspected tagged implementation and test definitions but did not rerun the suites, so the check counts are reported rather than reproduced. Whether the described behavior holds in the latest public release is likewise the author's statement, not something this report verified.

The reasonable conclusion is narrow. This is a documented, already-released set of interface changes to one desktop review tool, described by a community author with an unusually explicit account of what was and was not tested. For teams evaluating how they review agent-generated work, the interesting question is not whether tabs exist but whether per-file view and position state, plus non-disruptive background reads, reduce the cost of switching between artifacts. That question is answerable only by trying the tool in your own environment, and the source material does not answer it for you.

## Key points

- A community author states AIClaw v3.7.11 added a docked reading area with multiple file tabs and v3.7.12 added per-file reading state, both shipping on October 13, with the implementation said to remain in v3.7.14.
- Each open file keeps its own selected view, diff layout and scroll positions, with separate keys for source, rendered Markdown, snapshots and each diff layout; this state lives in memory and is cleared when a tab closes or the session changes.
- Background reads are assigned request identifiers and update their own tab without taking selection away from the file the user is viewing, and results for closed tabs or previous sessions are ignored.
- The author reports a public desktop smoke test covering tab reuse, scroll restoration, diff retention, keyboard switching and late-result handling, with suite totals of 104 checks in v3.7.11 and 133 in v3.7.12, described as suite totals rather than tab-specific counts.
- The author states they inspected tagged source and test definitions but did not rerun the suites, and that the checks do not establish native window behavior on every operating system or display arrangement.

## Practical implications — editorial interpretation

Editorial interpretation: if the described behavior holds, reviewers who move between an explanation, a query and a recorded diff can keep each file's view mode and scroll position and will not be pulled to another file by a slow background read. The docked reader still consumes horizontal space, cached tabs are not a disk refresh, and the reading state does not survive a restart or session switch, so the benefit is continuity within a session rather than persistence.

## Limitations and unknowns

This is a community post, not vendor documentation, and the release notes, test totals and current-release claims are the author's statements rather than independently verified facts. The author says they inspected tagged implementation and test definitions but did not rerun the suites. The reported checks are suite totals, not tab-specific tests, and the window-boundary cases are described as simulated, so native window behavior across operating systems and display arrangements is not established. No pricing, availability or platform support details are provided, and this report did not test the product.

## Sources

- [1] dev.to: How AIClaw Keeps Multi-File Reviews in Place with Docked Tabs
  https://dev.to/chowyu12/how-aiclaw-keeps-multi-file-reviews-in-place-with-docked-tabs-2ojb
  Retrieved: 2026-10-16T01:17:09.986Z

## Claim references

- The author states v3.7.11 introduced a docked reading area with multiple file tabs and v3.7.12 added per-file reading state, both shipping on October 13, with the implementation still present in v3.7.14. [source 1]
- In a normal window the Electron host attempts to add up to 640 pixels of width, bounded by the current display's usable area, and restores the original position and width when the reading area closes. [source 1]
- The preview store keeps an array of file previews and a separate active selection, reusing a tab and cached content when a file is already open in the session. [source 1]
- Scroll positions use separate keys for source, rendered Markdown, before/after snapshots and each diff layout, because positions are not interchangeable between views. [source 1]
- Each read is assigned a request identifier, and on completion the store checks that the tab still exists and the session matches, updating the tab without unconditionally activating it. [source 1]
- The author reports suite totals of 104 work-interface checks in v3.7.11 and 133 in v3.7.12, describing them as suite totals rather than tab-specific test counts. [source 1]