Recent Files for Obsidian puts your last opened notes in the sidebar

One recency list for a vault that has outgrown folders

The plugin does one thing and the README says so in the first line: it displays a list of most recently opened files in the sidebar. The value is not the list itself, it is the fact that the list is a permanent sidebar view rather than something you open.

The problem it addresses is easy to recognise in Obsidian. A vault with a few hundred notes develops projects, and a note is not filed under one project, it is worked on for a fortnight and then untouched for a month. Folder structure answers the question of where a note lives, and search answers the question of where something is written about. Neither answers which note you were last editing, which is the question that comes up every time you come back to the vault.

The plugin's answer is deliberately narrow. It is a list of recently opened files, and the list is configurable in three ways: you can exclude certain paths, exclude notes by frontmatter tag, and exclude bookmarked files. The third one is a nice touch of realism, since a file you have bookmarked is a file you intend to return to, and a recency list is not where you look for it.

The audience is therefore people with a large, active vault and no strong filing instinct, and it is a small convenience rather than a productivity system. It is also worth noting what the list is not: the README describes recently opened files, so a note you created and never opened again does not appear, and neither does one you edited for weeks without closing and reopening it.

The sidebar view reuses the file explorer interactions

The most interesting engineering decision is that the plugin does not invent a new interaction model. The README lists what you can do, and every item mirrors something the file explorer already does.

Clicking an item opens it, ctrl-clicking opens it in a new pane, and right-clicking gives you a menu. Dragging an item to an editor drops a link, dragging it to a header opens the file in a specific pane, and dragging it to a folder in the file explorer moves the file there. Hovering, or ctrl-hovering, shows a content preview, and the preview follows the setting of the Recent Files toggle in the Page Preview settings.

That last detail is the one to pay attention to, because it shows how the plugin avoids conflicting with the core editor. Rather than shipping its own preview implementation, it defers to the existing Page Preview configuration and adds one toggle for its own view. A plugin that re-implements hover previews ends up with a second, subtly different behaviour from the rest of the app, and this one does not.

The drag to a header to open in a specific pane is also more than a nicety. In a vault where you keep one pane for a long-running reference note and another for the thing you are working on, being able to drop a recent file into a specific pane preserves a workspace layout that a single click would collapse.

Frontmatter titles depend on a second plugin

There is one integration worth understanding before you install this, and it is in its own section of the README under other plugin support.

If you use the Front Matter Title plugin, the README tells you to enable the explorer module so that files are named in the Recent Files sidebar from the note's frontmatter title. The dependency is visible in the project's own dependencies: the devDependencies include a package called front-matter-plugin-api-provider, which is how the plugin talks to that other plugin's API.

The consequence is that the display name of a note in this list depends on how your vault is set up. With the Front Matter Title plugin installed and its explorer module enabled, a note titled in its frontmatter appears under that title. Without it, you are looking at file names, which for many Obsidian workflows is a different thing entirely, since the file name is often a slug with a date in it while the frontmatter title is the sentence you would search for.

The README does not describe a fallback for vault owners who do not use frontmatter titles at all, and it does not say what happens when the API provider package is absent. If your vault relies on frontmatter titles, this plugin is only as readable as that other plugin is configured.

The build is TypeScript through esbuild, with the Obsidian API pinned

The repository is a small TypeScript project, and its package.json shows the whole toolchain.

  "scripts": {
    "dev": "node esbuild.config.mjs",
    "build": "tsc -noEmit -skipLibCheck && node esbuild.config.mjs production",
    "eslint": "eslint . --fix"
  },

The build script type checks with tsc without emitting, then bundles with esbuild, and the dev script runs the same bundler in watch mode. The repository root holds main.ts as the source, manifest.json and versions.json for Obsidian's plugin metadata, styles.css for the view, esbuild.config.mjs for the bundler configuration, eslint.config.mjs and .prettierrc for the code style, and a pnpm-lock.yaml with the package manager field set to pnpm 10.20.0.

Two dependency choices are worth a look. The obsidian API package is not a versioned release but a tarball pinned to one commit of the obsidian-api repository, which is how the plugin compiles against a specific API surface rather than a moving one. And eslint-plugin-obsidianmd is in the dev dependencies, so the lint setup knows about Obsidian specific rules rather than treating the plugin as a plain TypeScript project.

The README does not give an installation walkthrough for end users, so the install path has to be read from the build configuration rather than from documentation: the package entry point is main.js, produced by the bundler from main.ts, which is the artifact Obsidian loads. The root also carries a .devcontainer/ directory, so a containerised development environment is part of the contributor setup.

Version history, the licence and the funding model

The release cadence shows a plugin that is still being worked on. Version 1.7.10 was published on 2026-07-21, a day after version 1.7.9 and 1.7.8 on 2026-05-12, which suggests a burst of small fixes followed by a quieter period. The last push to the repository was on 2026-07-21, the same day as the newest release, and the repository is not archived.

Those patch level numbers are the useful signal here. A plugin whose releases are numbered like this is shipping small adjustments to a working feature rather than reshaping it, which is what you want from a sidebar convenience, and it also means your Obsidian plugin updater will pull changes often enough that you should read the release notes before they land.

The licence is GPL-3.0. That matters more here than it might seem, because Obsidian plugins are distributed as source anyway, so the practical effect for a user is nil, while the effect for someone who wants to fork the plugin and keep the changes closed is real: the copyleft terms reach the derived work. The LICENSE file at the root is the text to read, and this is not a legal opinion, only a note that the terms are strict by design.

The funding model is straightforward. The README states that the plugin is provided to everyone for free, and that readers who want to support continued development can send money through GitHub Sponsors, PayPal or BuyMeACoffee. A free plugin with an explicit donation path and no feature gate is a healthier default than the usual pattern of a paid tier for the useful half.

Where a recency sidebar is the wrong answer

The limitation that matters is conceptual rather than technical. A recency list competes with your filing system, and if your vault is already organised by project, with links between notes and a tag structure, then the recency list is at best a second opinion and at worst a place where you keep finding the note you were editing last week instead of the one you need today. The README offers three filters, all of them subtractive, which is a hint about the shape of the feature: it can hide things, it cannot rank by anything else.

The second limitation is that it tracks opening, not editing. The description in the package.json is a list of files by most recently opened, and there is no option in the documented behaviour to sort by modification time or creation date. If what you actually want is the set of notes you have been working on, this is not it, and no amount of configuration changes that.

The third is the coupling to a companion plugin for display names, described above, and the fourth is that the README does not say anything about how the recency state is stored, whether it is per device, per vault or persisted, or whether it syncs. For a plugin whose entire content is a list, that is an oddly undocumented detail, and it is the first thing to check by hand on a second machine before you rely on the view.

The alternative is to make recency irrelevant. Search, links and a deliberate folder structure handle the same need durably, with the advantage that the answer travels with the vault and does not depend on where you last clicked. Recent Files for Obsidian is the better choice when your problem is genuinely that you cannot remember which of four hundred notes you were in, and the worse choice when the problem is that your notes have no structure.

Editorial conclusion

Recent Files for Obsidian fits an Obsidian user with a large vault who keeps reopening the same notes from several projects and wants one recency list in the sidebar. It does not fit a vault you have already organised well, since recency and structure are two answers to the same question, and it does not give you any way to sort by modified or created date. Before installing it, check whether you use the Front Matter Title plugin, because the note titles in the sidebar come from frontmatter only when that plugin's explorer module is enabled. The last push was on 2026-07-21, the newest release is 1.7.10 from the same day, and the licence is GPL-3.0.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. tgrosinger/recent-files-obsidian on GitHub