Option to wrap open tabs in the available window instead of just the current scroll on overflow

[rranjan14]

Check for existing issues

• Completed

Describe the feature

VS Code currently has this feature to enable tab wrapping where the open file tabs wrap and are shown. In Zed, currently, there's no support for it. Tab wrapping helps to find the open file quicker than the scrolling option. Having this feature will be pretty amazing.

If applicable, add mockups / screenshots to help present your vision of the feature

Zed:

VS Code:

[williamdes]

That would be nice to have. Here is the setting on VScode for reference.

https://code.visualstudio.com/docs/getstarted/settings

  // Controls whether tabs should be wrapped over multiple lines when exceeding available space or whether a scrollbar should appear instead. This value is ignored when `workbench.editor.showTabs` is not set to `multiple`.
  "workbench.editor.wrapTabs": false,

[morgankrey]

Hi all, closing this issue under the umbrella of "won't do". Our design direction does not agree with the premise, and would create complexity for other UI elements as the number of lines expand.
You're welcome to shift this to a discussion, but it's very unlikely we'd reconsider.

[themacguffinman]

I'm really sad about this, I've been watching this closely and entertained the idea prototyping code for this myself if the feature was accepted because this has been a real pain point preventing me from adopting Zed for big projects.

When developing complex features or debugging in a large project, there might be 15+ files involved that are not close together in the project directory. Horizontally scrolling between that many tabs is painful with a mouse & keyboard while Command/Ctrl + P navigation requires a lot of repetitive typing to switch back and forth.

Would a line limit (eg 3) make this feature request acceptable again? It'd also be appreciated if you could otherwise share what is the design direction you mentioned and how it might approach the 15+ open file problem I described?

[ArturoAHR]

I'd like to manifest my interest in this feature too, the need for it is exacerbated in Zed particularly since things like looking at the git commit history, search results and even renaming variables all open a new tab. Leading to me having to continuously close all tabs over and over. It's something minor in the grand scheme of things, but it interrupts my train of thought when working with Zed.

As @themacguffinman has suggested, a hard limit of tab rows could reduce the fan out of complex cases to account for in the UI, making the last row horizontally scrollable.

[brandon-hurrington]

It's your code base and it's your prerogative to do with it as you will, however I take issue with two of your assertions:

Our design direction does not agree with the premise...

The premise being that users want the ability to choose for themselves whether or not they have the ability to wrap tabs? I cannot follow this line of reasoning, user preference does not need to align with your company's mission statement. If the issue is maintaining the minimalist aesthetic, it seems there's more than enough screen real estate for any number of new panels for Agents, Collaboration, and the upcoming DeltaDB. Why not simply offer this as a new File Explorer Panel for this explicit purpose?

...and would create complexity for other UI elements as the number of lines expand.

This lands incredibly flat for me. Is that not the whole point of having created a brand new code editor from scratch with Rust and implementing your own UI framework, in order to solve the tough problems like this? VSCode, JetBrains, et al. offer what strikes me as a baseline feature for an IDE, yet there's no bandwidth to deliver this?

I've been on the Zed train for well over a year now and I love the tool but this is not just some "nice-to-have" fluff, it's directly impactful to QoL, especially if you are using Zed for its selling point: highly performant code editor. My performance in navigating our code base is meaningfully impacted by the inability to have an overview of all open files with their full file names displayed. Not every piece of code I want to interact with is a command click or window forward/back operation away, and horizontal scroll simply is not the right tool for the job in every one of those moments.

[everscending]

Wholeheartedly agree here. Please implement this feature we've all come to know and love that objectively makes our lives better.

[anshoriacc]

Just found this discussion, super sad. I've actually reinstalled and uninstalled Zed every few months just to check if this feature was finally implemented.

[Inlesco]

@morgankrey could you elaborate specifically how your "Design direction" doesn't go along with implementing multi-line / wrapping tabs for open files?

A limit for max rows with a strong default of 2 and a note for the user when he reaches the limit on how/where to increase the max rows count - that'd be perfect and sounds pretty straightforward.

If the UI breaking is a major issue, you can always set tabs.wrap.maxRows to 1 as default. And - when the horizontal scroll kicks in on the editor, display a notification / a tip explaining that multi-line tabs / tabs wrapping is available to configure.

I don't see anything wrong with giving us the flexibility while keeping the same defaults. If UI breaks in some cases - the user already knows it's probably because of maxRows setting > 1.

[codewizard-dt]

This is the right direction. An explicit choice to deny users the option to wrap tabs at the top is frankly bonkers.

Some people want to be able to see all their tabs in one glance. I can't imagine how an extra row or even two would interfere with other UI elements

[williamdes]

This is https://github.com/wdes/tab-atelier/ using gpui.rs that Zed uses, here is what wrapped tabs could look like. Since I use the same code as Zed does.

[kbilkis]

@williamdes check out the demo below - managed to make it look even better with expanding last tabs - looks exactly the same as it'd look on VS code

[kbilkis]

I've prepared a fully functioning POC #63321

works pretty flawless and looks in-line with the rest of the product:

Screen.Recording.2026-08-27.at.19.00.06.no.audio.mov

[kbilkis]

if anyone else wants to have wrapping in Zed, I've got a fork with wrapping that's tracking Zed's stable branch (auto-updates are also setup to track the fork) - https://github.com/kbilkis/zed-WITH-TAB-WRAPPING/releases

[Lyumih]

if anyone else wants to have wrapping in Zed, I've got a fork with wrapping that's tracking Zed's stable branch (auto-updates are also setup to track the fork) - https://github.com/kbilkis/zed-WITH-TAB-WRAPPING/releases

I would gladly use this if it were implemented as a plugin for Zed rather than a separate fork.

[kbilkis]

if it were implemented as a plugin

not possible as far as I'm aware :/

[kbilkis]

this feature just got released on the most popular fork of Zed - Gram

[XiaoYang943]

It would be fantastic if this could be merged into the main branch; I hope the upstream team will reconsider.

[ironchestgames]

I just switched from vs code because it was a nightmare to set it up for c23, but in Zed it worked out of the box, it even ships with gitlens and rainbow brackets as a part of the product which is great!

I can't say what projects I work on, but I do a lot of manual changes across many files at the same time and no agents allowed. It's not unusual to need to change 20+ files or even 30+ files at the same time. There's no way I can (or should have to) memorize where all files are located and what their names are. I need to find them first and then jump back and forth between them making the changes.

I can see around 8 tabs at the time, that's almost 4 full screen-widths of tabs to scroll through. I wonder, what is the suggested workflow for this in Zed?