Bring back the repository tree view as an in-app context selection tool
Problem
The previous repository tree view was not just a way to browse files. It was a core workflow feature.
It allowed users to:
- Navigate the repository directly inside Codex
- Select specific files without manually typing paths
- Right-click files and attach them to the current thread
- Ask Codex to inspect or work on a file with precise context
- Move from repository structure to agent instruction in one flow
The current "Open" action does not replace this.
Opening the repository in Windows Explorer, GitHub Desktop, or an external editor is useful for file management, but it does not solve the in-app context selection problem. It moves the user out of Codex instead of helping them give Codex better context.
Why this matters
Codex is most useful when the user can give it precise repository context quickly.
Removing or hiding the tree view turns a simple interaction:
right-click file -> add to chat / review this file
into a manual prompt-writing task:
go to this folder, find this file, inspect it, then use it as context
That is slower, more error-prone, and frankly a strange downgrade for a tool whose entire value depends on accurate code context.
Expected behavior
Please restore an in-app repository tree view with file-level actions such as:
- Add file to current thread context
- Review this file
- Summarize this file
- Ask Codex to modify this file
- Include folder as context
- Copy relative path
- Open diff if modified
Actual behavior
The app provides external open actions, but those are not equivalent.
"Open in Explorer" is not a context workflow. It is a way to leave the app.
Suggested fix
Bring back the repository tree view, or add an equivalent in-app file navigator focused on context selection.
The important part is not merely browsing files. The important part is letting the user select repository context without leaving Codex or manually typing file paths.
Summary
The old tree view solved a real interaction problem.
The replacement does not.
Please do not confuse "open the repo somewhere else" with "help the user provide precise context to Codex".
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Thanks for the duplicate suggestions.
I do not think this is exactly the same issue.
The problem I am reporting is not just that I want a draggable sidebar, or that the file tree toggle is unreliable.
Before updating, the folder button opened a repository tree for the active workspace. That tree was useful because it allowed me to browse the repo and select files as Codex context before any changes existed.
After the update, the same area appears to behave like a Review/Diff panel. When there are no unstaged changes, it shows an empty state:
That is useful for reviewing changes, but it is not a repository file tree.
The missing workflow is:
A review panel cannot replace this, because it only becomes useful after files have changed.
So the core issue is:
For a coding agent, the repository tree is not just visual navigation. It is part of the prompting and context-selection workflow.
Additional finding
The repository file tree does still exist, but it appears to be hidden or not initialized until a file tab is opened.
Steps I observed:
Review.+.Open file.This means the issue is not that the file tree is fully removed. The issue is that the default entry point for the repository tree is broken or hidden when no source file tab is open.
The tree should be available from the workspace/repository view even when only the Review tab is open and even when there are no Git changes.
A review/diff panel is not a substitute for the repository tree because the tree is needed before changes exist, to select files and folders as Codex context.
<img width="1510" height="2022" alt="Image" src="https://github.com/user-attachments/assets/2deb451b-ab96-43fe-bb99-9261b7c92f0b" />
One additional UX regression worth calling out: opening files/images from the current replacement flow tends to open a new tab/view and effectively loses or closes the repository/file-tree context. The old tree-view UX was much more familiar: you could keep the project structure visible, click through files/images, and preserve spatial context while deciding what to attach or ask Codex about.
That difference matters especially for image-heavy or data-heavy repos. The problem is not only that the file tree disappeared; it is that file/image inspection is now disconnected from context selection. The old flow behaved more like a normal IDE/file explorer: browse tree -> preview/open item -> keep browsing -> attach/use as context. The new flow feels like leaving the file-navigation workflow each time.
A coding agent is only as useful as the context you actually give it, and the interface for providing that context really matters.
The repository tree isn't just a nice UI feature, when it's missing or hidden, you're stuck manually figuring out what context to include.
Every other IDE keeps this because it works, hiding it doesn't simplify the app!
Additional requirement: make the repository tree a first-class workspace explorer
The restored tree is useful, but it is still significantly less capable than the Explorer in VS Code, particularly for SSH remote workspaces.
The minimum expected capabilities are:
.git, caches, build outputs, andnode_modules;A concrete inconsistency today is that a video linked in an assistant message can be previewed, while the same file selected in the workspace tree cannot. Folder paths emitted in messages are also not actionable and cannot reveal or expand the corresponding directory.
The goal does not need to be a complete IDE inside Codex, but the workspace tree should provide the baseline navigation, preview, context-selection, path-copying, refresh, and visibility controls expected from a modern coding tool.