fix(desktop): keep code and diffs out of the tool overflow window - #71678
Merged
Conversation
A run of 3+ adjacent tool calls collapses into the 6.75rem `.tool-group-scroll` window. That is right for status rows, but a patch or execute_code row's body is a code block the user reads, and the window squeezed it to a ~2-row viewport behind a fade mask. The CSS break-out (`:has([data-tool-row][data-tool-open])`) already lifts the cap once a row is expanded, which is why most tools are safe to bound. It can't help here: the user has to notice the clipped block and expand it before the code is legible. Extend the existing UNBOUNDABLE_TOOLS opt-out to the code-bearing tools behind an `isUnboundableTool` predicate, deriving the file-edit names from `isFileEditTool` so a newly supported edit tool can't be exempt in one place and clipped in the other. `terminal` stays boundable: console output is a log tail whose last lines are the ones that matter, which is exactly what the window pins. Verified in Chrome against the app's compiled CSS: a 3-call run carrying a 520px diff rendered at 108px before, full height after.
Contributor
૮ >ﻌ< ა ci reviewran on 7f29710 ℹ️ InfoDesktop E2E visual evidence · View test artifacts · View job1 visual diff. inline evidence is publishing... |
randlee
pushed a commit
to randlee/hermes-agent
that referenced
this pull request
Aug 11, 2026
…-overflow fix(desktop): keep code and diffs out of the tool overflow window
prmartinow
pushed a commit
to prmartinow/hermes-agent
that referenced
this pull request
Aug 26, 2026
…-overflow fix(desktop): keep code and diffs out of the tool overflow window
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A run of 3+ adjacent tool calls collapses into the 6.75rem
.tool-group-scrollwindow added in #57913. That's the right call for status rows, but apatch/write_file/execute_code/read_filerow's body is a code block the user reads, and the window squeezed it into a ~2-row viewport behind a fade mask.This extends the existing
UNBOUNDABLE_TOOLSopt-out — the same mechanism #64679 used for clarify forms and #65142 used for generated images — to the code-bearing tools.Why the existing break-out isn't enough
.tool-group-scroll:has([data-tool-row][data-tool-open])already lifts the cap once a row is expanded, and it works — that's why most tools are safe to bound, and this PR leaves them bounded.It can't cover this case.
clarify/image_generaterender their own components and never emitdata-tool-row, so the rule can't reach them at all. The code tools do emit it, but the user has to first notice the clipped block and expand it before the code is legible — reading a diff shouldn't require discovering an affordance.Notes
terminalstays boundable on purpose. Console output is a log tail whose last lines are the ones that matter, which is exactly what the window pins. Exempting it too would swallow the feature whole, since nearly every long run contains one.isFileEditToolrather than re-listed, so a newly supported edit tool can't be exempt in one place and clipped in the other.UNBOUNDABLE_TOOLSis no longer exported;isUnboundableToolis the single entry point.Test plan
Verified in Chrome against the app's compiled Tailwind CSS (measuring real laid-out height, since jsdom does no layout). A 3-call run carrying a 520px diff:
npx vitest run src/components/assistant-ui— 209 passednpx tsc --noEmitcleannpx eslintcleanUnit tests assert the invariant (every
isFileEditToolname is unboundable;terminal/web_searchstill bound) rather than snapshotting the set's contents.