Then again, I see that the top buzz in the industry is about Claws and letting LLMs run loose with only a handshake agreement to be safe, and I already know the answer.
This is why allot run dev containers but agreed this really should be top priority but instead is probably in the "maybe if we have a major security incident" bucket of concerns as these things often are
that said, I'm not sure i plan on using it long term - as someone else pointed out, the lack of extension sandboxing does make me feel a bit uncomfortable for extensions like this that aren't backed by large entities.
Beyond the core concept, there's also
- A heatmap that colors files based on recency
- Deleted files appear in the tree where they used to be
- A pinned section for files that are not recent but handy
- File history, diff search (pickaxe) and git log -L line/function history available from editor context menu
- File grouping based on the moon phase during the most recent commit (good luck finding alternative software for this)
One option is to vet a version yourself and disable auto-update, but that's not really feasible to spend time on for most people.
Easily navigate recent changes based on your pending work and Git history.

Switch between viewing pending (uncommitted) changes or files modified in configurable time periods. Pending Changes mode shows uncommitted changes (esentially what the Source Control view would give you)

Files are grouped by directory structure, with file counts on folders. Auto-expands to configurable depth.

Toggle heatmap coloring to give files distinct colors based on their most recent edit. Brighter colors = more recent.

This coloring is toggled in the Fresh Files view, but will also apply to the File Explorer.
At the top the tree, there is a special "pinned items" section. This is for files you want to keep handy independent of whatever the fresh file explorer is showing you. You can pin items with drag&drop or through the right click menu in the file explorer.

The pins are stored per workspace.
Displays info at the top of the tree view:
Both options can be individually disabled.

Note: The extension tracks the most recent commit per file only. If a file was modified by both a filtered author and a non-filtered author within the time window, the file will be hidden entirely (because the most recent commit is what's filtered). This is a deliberate simplification - for deeper history analysis, consider using something like GitLens or learning more than 5 git commands.
Organize your files in different ways beyond the standard folder structure:

File Structure - Traditional folder hierarchy
Author - Files grouped by who last modified them
Commit Hash - One group per commit
As well as two additional groupings for advanced git blame use cases.
git blame moon)Uneven distribution of commits during the full moon can indicate werevolves among your contributors.
git blame universe)Includes Pluto.
Note: This is astronomy (hard science), not astrology (garbage). If you want to know if you will have merge conflicts with the changes made by a sagitarius, you need to look elsewhere.

Use "Fresh Files: Quick Open" to get a quick pick showing files from your Fresh File Explorer view. Type to filter by filename or path, then select a file to open it. This is similar to VS Code's Ctrl+P, but filtered to only your fresh files, with some additional actions on top.
Features:
Note: the quick open excludes deleted files. You'll have to access those from the tree.
Works with:
Submodules:
I wanted to do more with submodules just for the fun of it but turns out it's not fun at all.
The extension adds several search features.
| Mode | Question it answers | Searches |
|---|---|---|
| Search in Fresh Files | Where is x in my current work? |
File contents, on disk, scoped to fresh files |
| Search in Found Files | I want to find y in all files that contain x. |
File contents, on disk, chained from a previous search |
| File History | What's the full history of this file? | Git log for an entire file, following renames |
| Diff Search | When was x ever added or removed? |
Git diff history across all commits (pickaxe) |
| Line / Function History | What's the full history of this function or code block? | Git log for a specific line range or function name (log -L) |

Answers the question "when was this string ever added or removed?"
Access through the editor right-click menu ("Search Diffs for Selection").
Results appear in a tree view grouped by file and commit, and each match can be clicked to navigate to it.
Access via right-click in the editor → "Line/Function History".
Based on your selection, shows every commit that touched those lines or that function, following renames. This is a wrapper of git log -L.
A / B comparison: Mark any two commits as A and B, then click Compare to open a diff between those two versions of the file.

Available via:
The search icon in the Fresh Files toolbar will open VS Code's search view with all currently visible files pre-filled in the "files to include" pattern. This lets you search only within the files you're actively working on, respecting your current filters and time window. This searches file contents on disk. To search the tree itself, use CTRL+ALT+F.
You can also trigger the search from the quick pick.

Problem: "I want to find b in all files that contain a."
Solution: Search for a, then use this action to open another search editor scoped to the files you found with your first search, then search for b. This process can be chained as many times as you want.

The action is available only in search editors, not the search view. But you can easily open your search view as a search editor.
Configuration:
freshFileExplorer.openSearchInEditor: Open searches in a Search Editor tab instead of the Search viewfreshFileExplorer.searchPatternMaxLength: Maximum pattern length per batch. Set a lower value if you encounter command-line length limits on your OS, or a higher value if your searches are getting batched. The default (4000 chars) is very conservative and can likely be set much higher on Linux.When you have many files or very long paths, VS Code's underlying search mechanism (ripgrep) can hit OS command-line length limits. In this case, the file list will be split into batches which will open as separate search editors.
There are several new action buttons in the search editor results:
You joined a new company and the codebase has thousands of files. Most haven't been touched in the last 75 years. But the file explorer shows everything, making it overwhelming to find where active development is happening.
| Approach | How it works | Friction |
|---|---|---|
| Default VS Code | Browse folders manually, maybe search for recent commits in Source Control | High - requires mental context switching, no visual overview |
| GitLens | Use "Commits" view to see recent commits, then navigate to files from there | Medium - commit-centric view, extra clicks to open files |
| Fresh File Explorer | Open the Fresh Files panel, see all files modified in last 30 days as a file tree | Low - immediate visual overview, familiar tree navigation |
You remember a file existed, but it's not there. Was it renamed? Moved? Did you misremember the path? Have you been drinking again? It's someone else's fault this time, but you're questioning your own sanity.
| Approach | How it works | Friction |
|---|---|---|
| Default VS Code | Search for the filename, find nothing, assume you're wrong | High - no hint that deletion occurred |
| GitLens | Would need to think "maybe it was deleted" and search commit history | High - requires the right mental model |
| Fresh File Explorer | Deleted files appear right where they used to be | Zero - it's still there, just marked as deleted |
Pain Point: You deleted files and realize you need them. They're committed to git but you wish it was easier to get them back.
| Approach | How it works | Friction |
|---|---|---|
| Default VS Code | git log --diff-filter=D, then git checkout <hash>^ -- <path> |
High - requires git expertise |
| GitLens | Find the deletion commit, view file at revision, copy content | Medium - several steps |
| Fresh File Explorer | Deleted files are there, right-click → "Resurrect" | Low - one-click restore. Works on multiple files at once. |
You make a commit but now your "pending changes" view is empty. You've lost the mental map of which files you were touching. This actually discourages small, frequent commits because you want to keep that overview.
| Approach | How it works | Friction |
|---|---|---|
| Default VS Code | Pending changes disappear after commit, must remember or check git log | High - punishes good commit practices |
| GitLens | Can view recent commits, but context switch required | Medium - the information is there, but in a different place, and you can only have so many views open at a time |
| Fresh File Explorer | Set time window to "Last 7 days" - your committed files still appear, organized by directory | Low - commit freely, overview persists |
Pain Point: A large automated change (formatting, linting, dependency updates) pollutes your view of what actually changed.
| Approach | How it works | Friction |
|---|---|---|
| Default VS Code | No built-in way to filter by author | High - must use terminal commands |
| GitLens | Can filter by author in various views | Medium - need to know where to look |
| Fresh File Explorer | Filter out the person doing the formatting, or (it was you, wasn't it?) the commit where it was done | Low - visual multi-select, instant feedback |
Pain Point: There just aren't enough todo list apps out there.
| Approach | How it works | Friction |
|---|---|---|
| Default VS Code | Is not a todo list | High - must vibe-code your own todo list |
| GitLens | Is probably not a todo list | Medium - I don't know, maybe it even has a todo list |
| Fresh File Explorer | Is also a todo list | Low - Can't miss it |
Yes. It might even be the only piece of software that does that.
Look under freshfileexplorer. to see all configurable settings.
If you find a bug or have an idea for a faster horse, open an issue.
For bug reports, it is extremely helpful if the problem is reproducible on a public repository.
Fresh File Explorer is not a GitLens replacement. It's a more focused, opinionated tool oriented around finding things you need right now. It doesn't make commits, manage branches, stashes, tags...
Use Fresh File Explorer when
Use GitLens when

Because one of those 25 is actually very similar to Fresh File Explorer, some more comparison can be found here.
This is above average for a VS Code extension.
(a chatbot instructed to pretend to be Linus Torvalds)