OpenCode 2.0.30 brings code review closer to the session

OpenCode 2.0.30 puts more of the review process beside the coding session. The October 15 release adds docked terminal diffs and restores two desktop conveniences from V1, a summary of each completed turn’s file changes and keyboard navigation between session tabs.

The useful question is how these controls help a developer decide what to inspect next. A list of touched files can point you toward a change. A patch shows what happened inside it. Neither establishes that the result meets the request or that the relevant tests passed.

Enable the desktop summary before looking for it

The desktop summary is off by default. Enable Changed files under Settings → Preferences → Timeline. The merged implementation shows changed paths, additions and deletions below a completed turn, with an expandable diff for each file. More than five files are tucked behind Show all.

Its input is the session’s recorded snapshots and completed turn markers. Running turns, turns without recorded file changes, sessions without those markers and sessions with snapshots disabled do not request a summary. Prompts delivered while a turn is running belong to that turn. Undelivered input does not. An absent summary therefore needs context before you interpret it as a clean working directory.

File paths can appear before counts and patches finish loading. A file reverted by a later step can disappear from the list when the diff arrives. Wait for that detail before treating the initial list as the final set of changes. These are documented implementation behaviors, not observations from a ByteForward test run.

Terminal diffs now dock by default

In the terminal interface, run /diff inside an active session. The change that graduates the side panel makes docking the default, so there is no experiment to enable. Older configuration entries for experimental["diff-panel"] are ignored rather than rejected.

Opening the viewer from the home screen still uses full screen because there is no session beside which to place it. A remembered full screen preference and the terminal’s width can also keep it from appearing as a side panel. These are useful checks if an upgraded installation looks different from the headline description.

Check focus before using diff shortcuts

The panel implementation lets f switch between docked and full screen views without remounting the viewer. Review state, scroll position and loaded data remain in place. That continuity is the practical attraction of the design when you move between a conversation and a large patch.

Keyboard input belongs to the focused area. Diff shortcuts act while the panel has focus. With the session focused, those same keys go into the prompt. The footer shows ctrl+x ← as the route back to the prompt, and the inactive area’s hints are dimmed. If a shortcut seems ineffective, check where input is going before repeating it.

Keeping the session visible may reduce the need to reconstruct what an agent was asked to do while reading its patch. That is an inference from the interface design. The release evidence does not establish a measured improvement in review speed or defect detection.

Terminal width changes the review layout

The responsive layout change specifies three width bands, measured in terminal columns. A narrower window can change both placement and navigation, even when the command is the same.

• At 108 columns or more, the viewer can dock beside the session.
• From 88 through 107 columns, it uses full screen with a file tree and inset cards.
• Below 88 columns, it uses a compact full screen layout without the file tree.

An explicit f toggle saves the full screen choice in diffs.fullscreen, so reopening the viewer can retain it. Full screen forced by a narrow window is not saved as that preference. The viewer stays mounted across responsive layout changes, preserving its review state. If you need the file tree on a small display, widening the terminal is a documented way to reach the layout that includes it.

Jump to sessions that need attention

The desktop’s restored navigation commands use Option plus the up or down arrow to move through visible session tabs. Add Shift to move to the previous or next unread tab. The change restores command registration lost after removal of the legacy layout, and preserves the V1 command identifiers so saved custom bindings still apply.

Unread follows the tab’s attention indicator. It includes a pending permission or form, or unseen activity while the session is not busy. It should not be read as a list of every running job. The separate commands for moving between projects were outside this change.

The pull request includes a reviewer report that the tab tests passed, while noting that the native macOS Go menu was not checked. That is narrower evidence than verification across every operating system. ByteForward has not independently exercised these shortcuts.

Make the next review question specific

Consider a hypothetical task to add validation to a settings form. Start with the requested behavior, such as rejecting an empty value while preserving a valid saved setting. Then inspect the relevant implementation and test changes. An unexpected edit to an unrelated configuration file deserves an explanation even if the overall patch is small.

Review at two levels. During the conversation, ask whether the last completed piece of work matches the instruction you gave. Before accepting the whole task, inspect the final combined change and run checks appropriate to the project. Several individually reasonable edits can interact badly, and a successful test only answers the behavior it actually covers.

If the question is how a long session reached its result, ByteForward’s guide to AgentPlay session replays covers reconstructing tool activity from existing logs. That is a useful companion question when the final patch alone does not explain a retry or an unexpected detour.

Check the version and installation route

The official download page lists terminal installation routes and desktop downloads for macOS, Windows and Linux. Use the route appropriate to your existing setup, and confirm which version you actually launch before looking for these controls. A published release entry does not establish that every local installation has already updated.

For anyone still on V1, ByteForward’s OpenCode 1.19 update and migration guide explains the separate move to V2 and why existing integrations deserve a compatibility check.

This article is based on the official release notes and merged implementation discussions checked on October 16, 2026. We did not install this release, run its test suites or benchmark its performance. The release date is October 15. Its publication hour and timezone were not established.

Illustrative software development photo by Jonathan Richard of Compagnons on Unsplash under the Unsplash License.