Codex App: View > Toggle File Tree is enabled but does not reliably reveal the file tree

Feedback submitted: 044cebec-db9c-481d-966b-a527df67e3e3

I can reproduce this on macOS with Codex 26.429.20946 (2312). Cmd+Shift+E is registered in View > Toggle File Tree and the menu item is enabled, but invoking it does not reliably reveal the file tree. I also verified that clicking View > Toggle File Tree through macOS accessibility succeeds, so this looks like the command reaches the app but the file-tree panel state does not consistently become visible.

I can reproduce this as well on macOS 26.4.1 (25E253), arm64, with Codex App 26.429.20946 (2312).

In my case, View > Toggle File Tree is enabled and shows Shift+Cmd+E, but selecting it from the menu or using the shortcut produces no visible change. I also checked via macOS accessibility that the menu item is enabled and can be invoked, so this does not look like a disabled menu/keyboard shortcut issue. The command appears to reach the app but the file tree does not open or reveal itself.

Also seeing this on Codex Desktop 26.429.30905 on macOS.

In my case, it is not limited to one project/workspace. The upper-right file tree icon is gone entirely across projects, and View > Toggle File Tree does nothing visibly.

I tried resetting:

• selected-remote-host-id
• app-shell:right-panel-width:v2:/local/:conversationId
• Codex Desktop Electron UI/cache storage

The menu item remains present, but there is no visible file tree UI or icon.

same here win11 . File tree toggle not working
Name PackageFullName Version
---- --------------- -------
OpenAI.Codex OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0 26.429.3425.0

Same here.
Macos 26.429.30905 (2345). Toggle file tree not working.

feedback here : 019deada-5f91-7af1-be54-60827335dc15

same here

no solution ?

Feedback submitted: 044cebec-db9c-481d-966b-a527df67e3e3

Thanks for the feedback ID.

I found a partial workaround and a few related observations that may help debugging this.

A faster workaround than Cmd+P is to move the mouse to the upper-right area of the Codex window. A floating file panel may appear. After clicking into it, there is a folder button. Clicking that folder button can sometimes bring back the missing file tree.

However, this workaround is not very discoverable and does not feel like a reliable replacement for View > Toggle File Tree.

I also noticed that the built-in file preview sometimes fails to open document files such as .doc, .pdf, or .ppt. These files may open correctly at first, then fail later. Restarting the Codex app seems to make them open again.

One more detail: in this version, the stale refresh issue seems to mainly affect the floating file panel. If files are renamed, moved, deleted, or added outside the Codex conversation flow, the floating panel may not immediately reflect those changes, and stale entries can become unclickable.

I understand the floating panel may be intended mainly for files generated inside the conversation, but from the user side it looks like a file-navigation surface, so the behavior is confusing.

Hope this helps narrow down whether the issue is in the file-tree visibility state, the floating panel state, or the preview/viewer state.

no solution ?

Not yet. The file tree has entered stealth mode. I’m almost getting used to it being invisible 😅

I am also experiencing this on MacOS arm64 with a version of Codex desktop I installed today.

This is a major useability issue not to be able to see the file tree at all.

I do not plan to use Codex until this is fixed. I will switch to an edictor that allows me to see the file tree of the project I'm working on.

I can confirm this makes the macOS Codex Desktop app effectively unusable for real project work. Without a reliable file tree, the user cannot inspect project structure, open files predictably, or recover navigation state.

The workaround of clicking file cards generated in assistant responses is not sufficient, because it depends on the model having already mentioned the relevant file. The app needs a deterministic way to reveal the workspace file tree.

Expected minimum fix:

1. View > Toggle File Tree should always reveal the file tree if a workspace is attached.
2. If no workspace is attached, show an explicit message.
3. The file tree/sidebar state should be resettable from the UI.
4. The sidebar should be resizable and persist its width.

same here win11 . File tree toggle not working Name PackageFullName Version OpenAI.Codex OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0 26.429.3425.0

Updated today but still no file tree. Are you joking gıys ???

I know this is old thinking, but I miss the file tree as well and the git commit like it has in Cursor so that I can see all the changes that are being made in a file tree.

same here
Codex: 26.505.10851
Windows 11, version 25H2

reported 87781949-7d4d-4990-bf3b-5b88499a866a

I’m seeing the same/similar issue on Windows.

Codex App version/package: 26.429.8261.0
Platform: Windows
Symptom: File Tree panel does not appear at all. View/shortcut path appears ineffective; Ctrl+Shift+E does nothing visibly. Other panels still work normally.

This persists after a clean restart. It does not appear to be caused by a missing workspace path. The app logs do not show an obvious fileTree/readDirectory error, but startup repeatedly reports unsupported feature enablement for workspace_dependencies, which may or may not be related.

I’m seeing the same/similar issue on Windows.

Codex App version/package: 26.429.61741.
Platform: Windows
Symptom: File Tree panel does not appear at all. View/shortcut path appears ineffective; Ctrl+Shift+E does nothing visibly. Other panels still work normally.

Can't someone at openai use Codex to fix Codex App at lightning speed?

Still not fixed. 😔

@codex-maintainers

Still not fixed. 😔

Having this issue as well

Having this issue as well.

macos and Version 26.506.31004 (2604), please fix

on X the codex team act like they actively doing everything to make it better, seems like it's been months that this "simple" file tree has been bugged say a lots about they care for real users

Still not fixed. 😔
Is it hard to do, or just not a priority?

Since the file tree was still playing hide-and-seek, I decided to build a small local workaround myself:

https://github.com/Theoz001/codex-file-tree

It opens a file-tree and file-preview UI inside the Codex App built-in browser, so I can still browse the current workspace when View > Toggle File Tree does not reveal the native file tree.

It is intentionally local-only: the preview server binds to 127.0.0.1, does not upload files, and write actions are guarded behind Write mode plus a per-process write token.

This is not meant to replace a native fix. If the Codex App file-tree visibility bug is fixed upstream, this plugin becomes much less necessary.

If anyone else is running into the same issue, feel free to give it a try. If it helps, a star would be appreciated.

seeing issues with this as well the old codex app was alot better and felt more like a super app

Same issue here. Windows 11.
Codex 26.506.31421

Has been happening for about 2 weeks now. clicking 'Toggle File Tree' does nothing.

I’m still seeing this in the current Codex Desktop version 26.506.31421.

Additional symptom: the folder icon that used to appear in the top-right corner is now gone, and View > Toggle File Tree still does not reveal the file tree or provide any visible feedback.

So this appears to remain unresolved in 26.506.31421, not only in the earlier 26.429.x builds mentioned above.

I’m seeing this too on macOS.

Codex app bundle:

• CFBundleShortVersionString: 26.506.31421
• CFBundleVersion: 2620
• Session logs report app version: 0.130.0-alpha.5

In my case, View > Toggle File Tree is present and enabled, but selecting it does not visibly open or toggle the file tree.

I also inspected local persisted state and tried changing ~/.codex/.codex-global-state.json keys like:

• app-shell:right-panel-width:v2:/
• app-shell:right-panel-width:v2:/local/:conversationId

but those appear to control a right-side panel width, not the file tree.

Local bundle inspection suggests the native menu command exists (toggleFileTreePanel / toggle-file-tree-panel), but I could not find a corresponding frontend action handler analogous to the handlers for toggle-sidebar, toggle-terminal, toggle-browser-panel, or toggle-diff-panel.

So this looks like the menu command is wired into the native menu but not reliably connected to file tree UI state.

Thanks for reporting this! We have a fix coming soon.

hi me too :

Codex Version 26.513.31313 (2867)
Mac OS Tahoe Version 26.4.1 (25E253)

Same issue here, but I found a workaround:

• CMD+P to search files
• Type any file name and press enter
• Click the double-folder icon on the top-right, that opens a file tree

<img width="556" height="250" alt="Image" src="https://github.com/user-attachments/assets/fd623b75-1f27-4cd8-9026-50f023078fad" />

Same issue here. Windows 11.

26.513.40821

Still reproducible on Codex App Version 26.513.31313 (2867).

View > Toggle File Tree is still present in the menu, but it does not reveal a usable file tree. This is not just a cosmetic issue. It breaks the direct file reference workflow, which is essential for prompt composition.

A common workflow is: I create or modify a specific file such as design.md, then I want to reference that exact file in the composer so Codex can read it and continue the task. Without a reliable file tree or @file picker, I have to manually copy the path, switch to another tool, or ask the agent to search for the file.

In large projects with many design/spec/architecture files, asking the agent to rediscover the intended file wastes tokens, adds latency, and can attach the wrong context.

Please treat this as a high-priority UX regression, not a minor sidebar bug.

I can still reproduce this on Windows with a newer Codex Desktop build.

Environment:

• OS: Windows 11 Home China, x64 (10.0.22631, build 22631)
• Codex Desktop package: OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0
• Codex package version: 26.513.4821.0
• Observed: 2026-05-20, Asia/Shanghai

Symptom:

• View > Toggle File Tree is available, but invoking it does not reveal a usable project file tree.
• The expected folder/file preview is not conveniently accessible from the desktop UI.
• The practical workaround is to open files indirectly, for example through file references/cards that appear in Codex responses, which is not an acceptable replacement for a normal project file browser.

Why this is a significant UX issue:

• File tree access is core to a desktop coding assistant workflow.
• Without a deterministic way to reveal the current workspace tree, users cannot conveniently browse project structure, inspect folders, or open files from the app UI.
• From the user side, this feels like either a bug or a design flaw: if a workspace is attached, Toggle File Tree should reliably reveal the file tree; if no file tree is available, the app should show a clear explanation rather than silently doing nothing.

Expected behavior:

1. View > Toggle File Tree should reliably reveal the project file tree when hidden and hide it when visible.
2. If the current thread/workspace cannot provide a file tree, the app should display a clear user-facing message.
3. The user should not need to rely on generated file cards or other indirect paths to browse/open project files.

This is still affecting the Windows Codex Desktop experience after the earlier "fix coming soon" comment above.

With today's release (26.519.31651), View → Toggle File Tree now successfully displays the file tree again; however, selecting the menu item again doesn't hide the file tree once it is shown, so the "Toggle" part is still broken. As it is now working, this comment could be called View → Show File Tree, since it does nothing if the file tree is already shown.

Finally,I can confirm this on the latest release, version 26.519.31651 (3017).

View → Toggle File Tree / Cmd+Shift+E now successfully shows the file tree, which is a clear improvement. However, the command still does not behave as a true toggle: once the file tree is visible, selecting the menu item again or pressing Cmd+Shift+E again does not hide it.

Expected behavior:

• If the file tree is hidden, Cmd+Shift+E should show it.
• If the file tree is already visible, pressing Cmd+Shift+E again should hide it.

So the current behavior is closer to Show File Tree / Reveal File Tree than Toggle File Tree. The remaining issue seems to be that the visible/hidden state is not being toggled symmetrically.

With today's release (26.519.31651), View → Toggle File Tree now successfully displays the file tree again; however, selecting the menu item again doesn't hide the file tree once it is shown, so the "Toggle" part is still broken. As it is now working, this comment could be called View → Show File Tree, since it does nothing if the file tree is already shown.

True

I’m seeing a related remaining issue: after closing/collapsing the file tree side panel, opening a file causes the folder tree to reappear again.

Steps:

1. Open a file in Codex Desktop.
2. Close/collapse the file tree / side panel.
3. Open another file.
4. The folder tree reopens automatically.

Expected: if I close the file tree, Codex should preserve that state until I explicitly reopen it.

This feels like the same toggle/state persistence bug: the command can reveal the file tree, but the app does not respect the user's hidden/closed state.

How I would intuitively expect the feature to work:

• There is a toggle (activated by icon / hotkey / menu bar option) which simply determines whether the file tree is shown at all.
• Within each project, the file tree initially shows the top level of the active project folder, and then remembers the last-used folder.
• If I move from project A to project B, the file tree should change to the second project's last known file tree location.
• The toggle is entirely independent of this, and does not reset the file tree for any project.

Still the same