Skip to content

[Feature]: Add a setting for default changed-files expansion in chat UI #2158

Description

@taroj1205

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

The chat timeline Changed files section is not configurable and can become very noisy when a turn includes a large diff.

A common case is updating or rebasing a branch, which can make the assistant message show a massive changed-files list in the chat UI. When that happens, the expanded file tree can dominate the thread and push the actual conversation content out of view.

Examples:

  • I update my branch from main and a turn now shows a very large changed-files list.
  • A rebase or merge touches many files and the chat becomes hard to scan because the changed-files block is expanded.
  • In some workflows, I want to read the assistant response first and only expand changed files when I explicitly need to review them.
  • In other workflows, I may want changed files visible immediately.

Proposed solution

Add an app setting that controls the default expansion behavior of the chat timeline Changed files section.

Suggested options:

  • Expanded
  • Collapsed

This setting should only affect the initial state when a given changed-files block is first shown.

If there is already a persisted user override for a specific thread/turn, that existing state should continue to win over the global default.

Why this matters

Different users want different review defaults.

A configurable default would:

  • reduce visual noise for users who often work with large diffs
  • avoid forcing a single opinionated default on everyone
  • make the chat UI more usable after rebases, merges, or large branch updates
  • still preserve the existing one-click expand/collapse interaction

Smallest useful scope

Add a single app setting in apps/web for the initial default state of chat Changed files blocks:

  • Expanded
  • Collapsed

The setting only affects first render when no per-thread/turn override already exists.

No redesign is needed.
Existing manual expand/collapse behavior can remain unchanged.

Alternatives considered

  • Make changed files collapsed by default for everyone.
    • Simpler, but opinionated and likely to create the opposite request from users who prefer expanded-by-default behavior.
  • Only auto-collapse when the changed-files list exceeds some threshold.
    • Could be useful, but adds more heuristics and edge cases than a simple user preference.
  • Keep the current behavior and rely only on manual collapsing.
    • This does not solve the repeated “massive expanded list” problem on initial render.

Risks or tradeoffs

  • Adds one more app setting to maintain.
  • Need to define how the global default interacts with existing persisted per-thread/turn expansion state.
  • The setting should be clearly scoped to the chat timeline Changed files section so it is not confused with diff panel behavior.

Examples or references

This request is specifically about adding a user setting for the assistant message Changed files section in the chat timeline.

Contribution

  • I would be open to helping implement this.

Activity

  1. added
    enhancementRequested improvement or new capability.
    needs-triageIssue needs maintainer review and initial categorization.
    on Apr 18, 2026
  2. lmerz1 commented on Apr 26, 2026

    @lmerz1

    Bumping!
    Really lengthy "files changed" lists could use, at minimum, a preferences toggle to be collapsed by default.

    While trying out a Swift project for the first time, I noticed there to be a really high number of build artifact files after invocations of swift build (typically due to swift package clean followed by a build).

    Scrolling up this when the list of files was expanded is not great default UX:

    Image

    The less-generalizable, albeit quicker fix just for greenfielding Swift projects specifically could be to "hardcode" not expanding .build/, and similar for other languages/frameworks where this type of behavior is commonly expected.

    But of course the cleaner implementation would be the settings toggle as described in the original issue comment above, with which only the top-level directories will be shown (fully collapsed list), or even being able to set some form of threshold or heuristic for when the changed file count becomes too large (i.e. a partially expanded list of changed files and then … for the rest).

    Oh, and thanks for building T3 Code! I really like it :)

  3. coygeek commented on May 7, 2026

    @coygeek

    Another concrete case for this: after a normal T3 Code agent turn completes, the chat timeline Changed files block can take over the visible message area and make the assistant's final summary hard to find.

    In my current example, the assistant finished with a useful final response, then the timeline rendered CHANGED FILES (22) +911/-1 below it. With the ChangedFilesTree expanded, the file tree occupies most of the viewport, so the actual final LLM message is pushed out of sight. To read it again I either have to scroll back up a lot, or manually hit Collapse all so only the top-level folders are visible. Once collapsed, the same turn becomes much easier to scan.

    This is not only a rebase/merge/build-artifact case. It also happens in ordinary implementation turns where the turnDiffSummary has enough touched files to dominate the chat timeline.

    A default collapsed preference would solve my case. A useful version could be:

    • keep the existing per-thread/per-turn persisted override winning when present
    • otherwise initialize each new chat timeline Changed files block from a user setting
    • optionally consider an automatic threshold later, e.g. default-collapse when file count exceeds N, but the simple setting described in this issue is already enough

    Expected UX: after an agent finishes, the assistant's final message stays easy to read first; changed files remain one click away via Expand all / View diff.

  4. added and removed
    needs-triageIssue needs maintainer review and initial categorization.
    on Jul 20, 2026
  5. locked and limited conversation to collaborators on Aug 15, 2026
  6. converted this issue into a discussion #6728 on Aug 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions