Project explorer continuously re-sorts and blinks every second (regression)

[tkossak]

Summary

The project explorer continuously re-sorts its file and folder listing approximately every second, causing all entries to visually blink/flash. This is a regression introduced in a recent Warp update.

Problem

After updating Warp, the project explorer sidebar constantly reshuffles its file and folder entries on a roughly one-second interval. The re-sorting produces a persistent blinking effect across all items in the tree, making it difficult to visually locate and click on files. The sort order is set to the default (unchanged by the user).

Expected behavior

The project explorer should display files and folders in a stable, consistent sort order. The listing should only update when the underlying filesystem changes (e.g. files added, removed, or renamed).

Actual behavior

Files and folders in the project explorer re-sort themselves approximately every second, causing the entire tree to blink continuously. This happens regardless of whether any filesystem changes are occurring.

Reproduction steps or desired workflow

1. Open Warp (v0.2026.04.29.08.57.stable_01 or later).
2. Open the project explorer sidebar for any project directory and wait about 10 seconds.
3. Leave the sort order at the default setting.
4. Observe that files and folders re-sort and blink approximately every second without any filesystem changes.

Artifacts

None attached.

Warp version

v0.2026.04.29.08.57.stable_01

Operating system

CachyOS Linux, kernel 7.0.0-1-cachyos (Wayland / KDE)

[oz-for-oss]

@tkossak

Here's what I found while triaging this issue:

This looks like a Project Explorer refresh/rebuild loop rather than an intentional sort-order change. I found related file-tree refresh issues, but not enough exact matches to mark this as a duplicate.

I have a few follow-up questions before I can narrow this down:

1. Could you attach a short screen recording showing the Project Explorer blinking/re-sorting for a few seconds?
2. Does the blinking also happen in a newly created small empty directory, or only in existing project/git repositories?
3. If you can share logs, could you attach Warp logs from a 10-second window while the Project Explorer is visibly blinking?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that project Explorer appears to be receiving repeated file-tree refreshes that rebuild its sorted list every second on Linux, causing visible blinking/reordering without intentional filesystem changes..

Triage

This is a Linux Project Explorer bug report affecting the workspace/file tree surface. The symptom is a stable directory view repeatedly rebuilding/re-sorting about once per second, causing visible blinking even when the reporter is not intentionally changing files.

Reproducibility

Medium. The issue includes a clear version (v0.2026.04.29.08.57.stable_01 or later), OS/windowing details (CachyOS Linux on Wayland/KDE), and simple steps. It is not high-confidence yet because there is no video/log artifact and the behavior may depend on Linux filesystem watcher events, project contents, or background processes touching files.

Likely area

The relevant code path is the Project Explorer FileTreeView, which rebuilds its flattened item list from repository metadata and sorts child paths through sort_entries_for_file_tree. Local repository metadata is driven by filesystem watcher events with a one-second debounce, then emits file-tree update events that can trigger FileTreeView rebuilds. A noisy watcher/update source on Linux could therefore produce the reported one-second blink/re-sort cadence even when the user does not see obvious file changes.

Duplicate check

I enumerated open issues and checked recently closed issues for matching Project Explorer/File Explorer blinking, re-sorting, flickering, and refresh symptoms. The closest open issues are about stale/slow file explorer refreshes or broader watcher debouncing, but I found fewer than two likely duplicates of this exact continuous every-second re-sort/blink behavior, so this should remain a standalone issue for now.

Question reasoning

1. Could you attach a short screen recording showing the Project Explorer blinking/re-sorting for a few seconds? — This is a visual UI symptom, and a recording would confirm whether entries actually change order, selection/hover state flashes, or the whole list repaints.
2. Does the blinking also happen in a newly created small empty directory, or only in existing project/git repositories? — This distinguishes a generic Project Explorer repaint loop from file watcher noise caused by project-specific files, git metadata, or background tooling.
3. If you can share logs, could you attach Warp logs from a 10-second window while the Project Explorer is visibly blinking? — Logs may show repeated repository metadata or filesystem watcher events matching the approximately one-second cadence.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[tkossak]

• Screen recording: https://github.com/user-attachments/assets/b9e4a780-a540-40b0-9966-bd7622e750a3
• I think SSH has something to do with it. When I restarted warp, the blinking stopped, but when i created new tab, SSH into remote machine, create new (local) pane on the bottom (switched focus to it), the blinking started again.
• logs: warp-logs.tar.gz

[oz-for-oss]

@tkossak

Here's what I found while triaging this issue:

Thanks for adding the recording and logs. The new SSH workflow points to remote-session metadata interacting with the Project Explorer, not just a user sort preference issue; the logs also show repeated watcher/metadata warnings shortly after the SSH session connects.

Maintainer details

I concluded that project Explorer appears to be repeatedly rebuilding/re-rendering its file tree after SSH remote-session metadata becomes active, causing visible blinking/re-sorting on Linux..

Triage summary

This looks like a real Project Explorer regression on Linux, with SSH/remote-session state now a key part of the trigger rather than just a generic sort-order issue. The reporter supplied a screen recording and logs, and the follow-up workflow is: restart Warp, open a new tab, SSH to a remote machine, create a new local pane at the bottom, focus it, then observe the Project Explorer repeatedly blinking/re-sorting.

Evidence

• Warp version: v0.2026.04.29.08.57.stable_01.
• OS: CachyOS Linux, KDE/Wayland.
• Reporter says the issue stops after restart and resumes after an SSH tab plus a new focused local pane.
• Logs show the SSH remote-server path becoming active at 12:08:41 (Received SSH hook, Remote server connected, Remote server ready).
• Immediately after that, logs include repeated repo-metadata warnings (No remote repository found for incremental update: /home/kossak) and repeated watcher permission failures on an inaccessible path under the user's home directory.

Likely code path

• app/src/pane_group/working_directories.rs computes per-pane-group working roots from terminal CWDs/local paths and emits DirectoriesChanged.
• app/src/workspace/view/left_panel.rs feeds those roots into FileTreeView::set_root_directories.
• app/src/code/file_tree/view.rs preserves remote roots alongside local roots, subscribes to RepoMetadataModel, and rebuilds/notifies on RepositoryUpdated and FileTreeEntryUpdated for both local and remote repositories.
• crates/repo_metadata/src/local_model.rs uses a 1-second filesystem watcher debounce and emits file-tree update events after watcher batches.
• app/src/remote_server/server_model.rs and crates/repo_metadata/src/remote_model.rs push/apply remote repo metadata snapshots and incremental updates.

A noisy remote metadata path, failed watch registration, or repeated no-op metadata update could therefore cause full file-tree rebuilds/notifications even when no user-visible filesystem contents changed, which matches the visual blink/re-sort symptom.

Suggested labels

bug, os:linux, area:workspace, area:ssh, repro:medium. I would drop needs-info because the follow-up provided a recording, logs, and a narrower trigger path.

Duplicate check

I enumerated all open non-PR issues and found related Project Explorer refresh/sorting requests, but no existing open issue matched the same continuous re-sort/blink after SSH plus local-pane focus. Leave duplicate_of empty.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[peicodes]

@tkossak I see from the video that .SpaceVim.d is the one causing the shuffle. What happens if you delete it? What if it's a different file that has two . in the name? I'd love to narrow this down a bit before marking it as ready-to-implement

[kevinyang372]

@peicodes I think this is caused by a pre-existing issue with our file tree refresh logic that is further exacerbated by remote server extension. I have a fix here: #10184