I should be able to disable the sidebar

[Haume0]

Reproduction steps

Every time I open a project, project goes to the sidebar. When i try to close i just use the close button and boom my freaking editor gone, thanks zed. Even better thing, you cant disable this "feature" unless you disable the whole ai features, who's idea to add this thing like that and that way?

Another thing this sidebar button destroys my muscle memory for my project files button, and again the only way is switching to the right side then my terminal and ai agent tabs are now shifted or i disable whole ai features from zed or switch to vscode back :) thanks.

Current vs. Expected behavior

NOW: No way to sidable or hide sidebar.

EXPECTED: To be able to hide or disable from settings!

Zed version and system specs

Zed 0.233.10
Windows 11 & MacOS Tahoe

Attach Zed log file

Zed.log

Relevant Zed settings

settings.json

Relevant Keymap

keymap.json

(for AI issues) Model provider details

No response

If you are using WSL on Windows, what flavor of Linux are you using?

None

[anilpai]

I want to completely disable this agent session sidebar. HELP !!

[zambetti]

Not sure if this helps, but it is possible to move the threads sidebar to dock on the right side in settings.json like this:

"agent": { "dock": "right", "sidebar_side": "right", ...

Since the threads sidebar appears and acts like a panel, I expected that it would be configured and referred to as "threads_panel" since this is the pattern that the other panels follow (project_panel, git_panel, outline_panel, collaboration_panel, etc).

Something like this:

"threads_panel": {
    "dock": "right",
    "button": true,
    "enabled": true,
    ...
},

It's strange that this new panel is called a "bar" since it is decidedly more panel-like than bar-like in comparison to the status bar and tab bar. It's also strange that it is referred to as "sidebar" within "agent" and lacks the word "threads" in the property, although "threads" appears in the UI.

[jameslkingsley]

This panel seems to also have replaced the Use System Window Tabs setting on macOS, so now when opening multiple projects instead of them being tabs it just completely replaces the current project and forces you to switch between them using this new panel. Would love an option to use the prior behaviour and disable this panel.

[franciskafyi]

Thank you for your feedback everyone.

We're implementing some changes asap based on yours and others feedback:

• The ability to Open Project in New Window from the Project Picker, even if the project is already open in the sidebar
• A setting to default to opening projects in a new window (similar to the CLI setting we added)

We do think that the sidebar is a helpful tool to organize your agentic work but we understand it's not for everyone. Keep the feedback coming!

[ArturAronov]

@franciskafyi is there way to completely disable the sidebar?

[macraig]

@ArturAronov not for the moment, but we're working on it!

[ArturAronov]

@macraig Thank you so much! Is there separate issue thread that I can track where it's discussed?

[macraig]

@ArturAronov we're discussing it internally with the team for now. I'll keep you updated on the status in this discussion.

[Andersos]

@franciskafyi Hi! Is there an issue i can follow so I know when i can change my setting? Thanks for being open en telling us about your work

[zambetti]

The threads list is useful, but the criticism likely comes from it being a separate panel with its own status bar button that feels heavier than necessary since it mainly controls the Agent Panel (a panel that controls another panel).

Rather than introducing a new panel, it would be cleaner to integrate the threads list directly into the Agent Panel with a “hamburger” button in the Agent Panel toolbar that toggles it. This would keep thread navigation tied to the conversation UI and avoid adding another independent panel.

The thread list could then appear on either the left or right side of the Agent Panel depending on the position of the Agent Panel as configured in settings.json.

There could be a setting to control default visibility of the thread list: visible, not visible, or visible only when there is more than one thread. And probably a setting to auto-hide/close the thread list when a thread is selected.

Perhaps the Agent Panel could be width-responsive, so that it shows the thread list automatically if it is wide enough (with a agent.minimum_threads_list_width exposed in settings.json).

To maintain feature-parity with this release, the Agent Panel would also need a new search ability, which could follow the established UI pattern of buffer search, with the ability to set the scope to search either a single thread or all threads.

As it is now, this separation can lead to odd layouts where the agent conversation and its thread list end up on opposite sides of the window (see screenshot below):

"agent": {
  "dock": "left",
  "sidebar_side": "right",

Looking at this screenshot, the “Search…” field in the Threads sidebar/panel feels off from a UI hierarchy perspective. It reads like part of the window chrome, which makes it seem like it searches more broadly than just threads.

At minimum, the placeholder should be more explicit: “Search agent threads…” or “Search agent conversations…”.

More fundamentally, it should feel like part of the Agent Panel rather than a separate surface, and be styled more like buffer search in terms of placement and visual hierarchy.

It looks even more like a global search when the Threads sidebar/panel is on the left. Too visually prominent for its scope, and the current labeling overstates (or under-describes) what it searches.

These UI hierarchy issues also point towards having the threads list be part of the existing Agent Panel.

Lastly, and in addition to all this, one of the biggest drawbacks of having two panels (one for threads and another for the agent) is that now two key commands are required to fully show/hide the agent threads and conversation.

[domindel]

the two should DEFINITELY merge into the agent panel,
at least as a toggleable option.

[danilo-leal]

We absolutely explored this design multiple times, but with regards to hierarchy, the sidebar's positioning is the in the best and most correct spot given what it is. It's a multi-project/workspace/worktree navigation surface, whereas the agent panel—and all other panels for what it is worth—are all part of a given workspace. With that in mind, it wouldn't make sense for something that displays cross-project information to be housed inside just one of the workspaces it allows you to navigate to.

For example, if you have a project called "personal-project" and then have three worktrees for it, you'll see that the workspace layout for each one can be different; e.g., one might have panel left open and panel right closed, the other might have the two panels open, the other might have all panels closed, etc. However, the sidebar is not part of any workspace, so it stays stable allowing you to navigate between projects that have different workspace configurations. So with that in mind, the sidebar is also not technically a panel, even though it looks like one.

[domindel]

@danilo-leal given that project/worktree menus are at the top bar and it being disabled when the disable_ai option is true: it only makes sense for having agents run on separate worktrees/projects at the same time. that is a neat feature i am not going to deny, but for a lot of us, its a giant waste of space and an extra click to hide it after switching threads. there should be an option to have the thread menu built into the agent panel and the threads sidebar hidden.

[zambetti]

It's a multi-project/workspace/worktree navigation surface
@danilo-leal

it wouldn't make sense for something that displays cross-project information to be housed inside just one of the workspaces it allows you to navigate to
@danilo-leal

While I can understand the rationale behind this design for the single-window multi-project/workspace/worktree highly-parallel use case, I’m not convinced it reflects the dominant usage pattern for threads specifically, or that it justifies the added complexity for more common simpler workflows. I also challenge the assumption that agent thread navigation belongs exclusively at that same level.

In practice, I suspect most users are in a relatively simple single-project single-worktree setup. In that scenario, elevating threads into a global sidebar introduces a lot of underused UI that has to be repeatedly hidden manually just to reclaim working space.

As a possible compromise, it might make sense for this new multi-project/workspace/worktree-agent-thread-navigation-sidebar-surface to be optionally disableable, and also offer a lighter-weight thread navigation UI that lives inside the Agent Panel for simpler scenarios.

The previous approach of navigating threads in the Agent Panel was basic and a bit clunky, but it felt like it was in the right place. It stayed close to the flow, got out of the way when no longer needed, and aligned with the idea of threads as an integral part of agent interaction.

That approach could be refined into something cleaner and smoother, without requiring a separate surface or structural changes to the overall UI layout.

[zambetti]

I've created another issue/discussion #55910 that is related to, but different than this one.

[macraig]

Hey everyone! Thanks again for all the feedback, we hear you. We're currently working on an option to disable the sidebar and will keep you posted as things progress.

[skorobogatydmitry]

The most odd thing I found about the panel is that it's shown even if

  "agent": {
    "enabled": false,

[Haume0]

Yea as i say its disables all ai features like; ai completion, inline edit etc. I want to be able to disable agent sidepanel seperately.

[macraig]

Hello again,

Thank you all for your patience, we know this has been a source of friction. After discussing internally, here's where we've landed:

New window/existing window setting: We're adding an open_behavior setting (similar to cli_default_open_behavior) with two options: "existing_window" or "new_window". By default, adding a project to the sidebar is the primary action. With new_window, opening in a new window becomes the default instead, so you no longer have to reach for the secondary icon button each time.

Consistent window management: We believe this inconsistency between CLI and UI window management contributed directly to the confusion, and we're fixing it. "Open in New Window" will now always open a new window, rather than reusing an existing one if the project is already open there.

Sidebar behavior: We explored ways to fully disable the sidebar, but ultimately the overhead and complexity of maintaining two separate surfaces for thread history made it difficult to do well. Rather than ship something half-baked, we've decided to keep the sidebar enabled as long as AI is enabled. Disabling AI will disable the sidebar as well.

TL;DR: If you set open_behavior: "new_window", the sidebar will stay closed and you won't need to interact with it at all. We hope this meaningfully reduces the friction you've been experiencing.

That said, we'd genuinely love to hear from you: will these changes be enough to keep Zed as part of your daily workflow? If there's still something blocking you, let us know. Your feedback is what helps us prioritize the right things.

Thanks again for your patience!

[zambetti]

Even a lightweight thread-switcher would need to handle concurrent threads, worktree switching, and similar complexity — we'd essentially be rebuilding the sidebar in a new place.
@macraig

This makes sense. With your explanation, I can see there's more than thread switching to accommodate, and the concern of fragmentation is understandable.

Reflecting on this more, my primary frustration with the new sidebar is simply how much horizontal screen real estate it occupies alongside the Agent Panel. Because I, and presumably many others, run Zed in a full-height window, the sidebar ends up being mostly empty space or old content, so I find myself repeatedly toggling it open and closed.

If a separate switcher is out of the question, would it be possible to allow the Agent Panel to be docked beneath the sidebar (by dragging or a setting)? That way, we could make better use of that vertical space and reclaim some crucial horizontal room.

A quick before-and-after mockup...

Please excuse the rough edges in this mockup. The redundant thread title looks a bit clunky, having the sidebar buttons sit underneath the Agent Panel isn't ideal, and the search field living above the entire combined area feels a bit misplaced hierarchically. This could definitely be solved more elegantly, but hopefully this helps illustrate the spatial concept.

[Haume0]

Yea good point, with sidebar actual editor section is so small you can't use it properly. Mock implementation is cool love to see something like that.

[domindel]

the "threads sidebar above chat" idea seems to be the best for both worlds, the real issue with the threads sidebar is the amount of horizontal space it takes, and the option to merge the agent panel and sidebar like this seems to address both the horizontal space and the dual implementation issue.

of course it would be perfect to have the toggle threads button inside the agent panel (and not in the ... dropmenu exclusively) and the bottom button hidden.

id love to see this idea turned into its own discussion so that it gets more attention.

excellent work @zambetti

[brodmo]

How about an additional "replace" option for the new "open_behavior" to bring back the old behavior without disabling AI entirely? That'd be my wish. I use AI but mostly one thread at a time so navigating projects via threads doesn't make a ton of sense for me. Essentially I would like the behavior of disabled AI while still having the option to use it. I think the current state of project navigation is just plain confusing if you don't primarily work via agent. There's really no reason for me to have multiple projects open in a single window if I can't even navigate between them or close them easily.

[Blond11516]

I want to +1 @brodmo's suggestion. I've spent the last few weeks getting frustrated with Zed, fully closing it many times per day to (unknowinngly) reset the window's open projects. I was pretty convinced Zed'd window management was bugged.

I usually have 2 or 3 windows open (BE, FE and maybe another side thing) and switch between different business projects (aka different products) regularly, each with their own set of projects/repositories. Currently, if I open a new window and try to open a project it will inconsistently either:

• open the project in the new window
• switch the old window over to the selected project, leaving the new window empty

I now know this is because of the multiple projects per window feature, but for me it's frankly been infuriating.

Having a "replace project in current window" option for "open_behavior" would be a much better fit for my way of working.

[domindel]

i forked zed to add the threads over chat feature in https://github.com/domindel/zed-55157
added the option to set Threads Sidebar Side to In Agent Panel,
this moves the threads sidebar into the agent panel on top of the chat.
and also added the option for the sidebar to move next to the chat if the panel becomes wide enough (width for that to trigger can be set in the settings)

the toggle threads button moves to the header of the agent panel when the sidebar is in the agent panel.
the threads sidebar is resizable vertically (if on top) and horizontally.

NOTE: this is meant to be a showcase of how this feature could be implemented, its not bug free, and definitely not perfect, but i think it shows that something like this is very possible with very little trouble.

[zambetti]

@domindel I just built your fork and tried it out (screenshot below), very impressive demo. It already feels great, and your changes look surprisingly lightweight.

Two thoughts:

• Hierarchy: Based on previous messages from the Zed team, I imagine this concept might be better received if the Agent Panel were integrated into the Sidebar, rather than the Sidebar's switcher being relocated to the Agent Panel. Conceptually, the Sidebar sits at a higher level than the panels of the project. That said, this all-in-one-place approach feels like a welcome space-saving improvement, and I'm curious to hear their feedback on your demo.
• Search/Filter Field: Moving the sidebar search field out of the titlebar is an excellent change. It fixes problems like Window-drag initiated from sidebar search field causes text-selection caret cursor #56107 and resolves the awkward Mac OS layout where that field boxes in the window controls when the Sidebar is on the left side. Moving it as you have done, reduces its prominence, which better matches its actual utility.

Great job. I'll keep using this for a while to get a better sense of how it feels long term.

[domindel]

thank you for your kind words!
unfortunately i am not experienced enough in rust or have enough time to maintain a fork of such a large project, so i don't plan on bringing over features from newer versions of zed.

i made this only to demonstrate that the idea you proposed (as i understood it) could easily be implemented, even with my lack of experience, without headache

the reasons i chose to integrate the sidebar into the agent panel instead of the opposite are

• the generic sidebar icon wouldn't make sense if it also housed the AI chat functionality. (and changing the sidebar icon to the agent panel icon when the option is enabled would be a UX mess)
• the threads selector should be toggleable. integrating the chat into the sidebar means opening the sidebar to select a session, and then hide the sidebar to get the same result as what's default in my implementation. and i assume that most users of this option will have the threads hidden most of the time.

the zed team's idea of the sidebar being higher in the hierarchy makes sense for people who use AI extensively and a nuisance for everyone who uses AI as a secondary helper.
programmers aren't just the two extremes of disable AI or use multiple agents across multiple projects. and i feel like zed has overlooked that fact.

[zambetti]

That makes sense. The demo is already more than enough to get a feel for how it could work. On both a dual-monitor setup and especially on my laptop screen by itself, it feels really good to use.

Nice work building this and showing that the idea is more than just a discussion on GitHub. Hopefully the Zed team gives it a spin and takes notice.

[macraig]

Hey! Thanks for the suggestion, we'll definitely take it into consideration. We're a bit low on bandwidth right now so I can't promise a timeline on it, but we'll keep it in mind. Since this is a bit different from the original sidebar disabling topic, might be worth starting a new discussion specifically for it so it doesn't get lost here

[zambetti]

Thank you @macraig! I opened a new discussion here about this topic #60233

[macraig]

Hey all! Just wanted to let you know that the changes I mentioned above are shipped and will be available on Stable next week. Thanks for bearing with us on this one!

[nguyen-vo]

Hi @macraig , when will the open_behavior setting for the Thread Sidebar mentioned above be released? I keep checking release note but I don't see it mentioned.

[Haume0]

in the settings at the first page when you open.