vscode-project-manager: manifest says 13.1.1, newest release tag is v12.0.1 from 2020

The newest release tag is six years older than the manifest

The extension manifest declares version 13.1.1 and requires a VS Code engine of ^1.78.0, and the change list at the top of the page heads itself with the release name 13.1. The releases attached to the repository tell a different story: v12.0.1 from 2020-11-24 and v11.3.0 from 2020-09-06, and nothing newer appears in the two most recent releases. So the code, the marketplace artifact and the tag history are three different timelines, with the gap sitting at about six years. The most recent commit recorded for the repository is dated 2026-09-24, which is the date that describes the source, while the release list describes the tags. If you are pinning an internal copy, pin the manifest version rather than a tag, and if you are checking whether a reported bug was fixed, look at the commit date rather than at the tag list.

Open source again, licensed two different ways

One line in the change list for 13.1 reads Fully Open Source again, which implies a stretch when it was not. The page still carries the funding table from that stretch: a PayPal donation link, a GitHub Sponsors link and a Patreon link for the author, under a Support section that asks you to consider supporting the extension. Licensing is described two ways as well. The licence recorded for the project is GPL-3.0, while the extension manifest carries the non-SPDX string SEE LICENSE IN LICENSE.md, and the root of the tree holds LICENSE.md rather than a file named LICENSE. Nothing on the page says which of the two a marketplace consumer is agreeing to, and no SPDX identifier appears in the manifest, so a tooling check that reads only package.json gets a pointer rather than a license name.

The command list and the walkthrough name the Edit command differently

Five commands are listed under Available Commands, and the fifth is a filter. The fourth is the interesting one, because it appears twice with two different names. The list gives Project Manager: Edit Project, described as editing your projects manually in projects.json. The section further down says the same thing with a plural, execute Project Manager: Edit Projects, and states that the file is opened for you. One of those two strings is not the identifier the extension registers, so a keybinding or a command palette search built from the list can miss. The other four are unambiguous: Project Manager: Save Project, Project Manager: List Projects to Open, Project Manager: List Projects to Open in New Window, and Project Manager: Filter Projects by Tag, which filters the favorite projects by selected tags.

projects.json accepts three path spellings and the sample ends mid tag

The list you edit by hand is a plain JSON array, and the page shows three entries of it.

[
    {
        "name": "Pascal MI",
        "rootPath": "c:\\PascalProjects\\pascal-menu-insight",
        "tags": [],
        "enabled": true,
        "profile": "Delphi"
    },
    {
        "name": "Bookmarks",
        "rootPath": "$home\\Documents\\GitHub\\vscode-bookmarks",
        "tags": [
            "Personal",
            "VS Code"
        ],
        "enabled": true,
        "profile": "VSCode"
    },
    {
        "name": "Numbered Bookmarks",
        "rootPath": "~\\Documents\\GitHub\\vscode-numbered-bookmarks",
        "tags": [
            "Personal",
            "VS Cod

Three things to read off it. Paths come in three shapes, an absolute Windows path, a $home prefix and a ~ prefix, and the note beside the sample says ~ and $home are replaced by your HOME folder. Each entry carries five fields: name, rootPath, tags, enabled and profile, so the profile feature from the change list is a field in this file rather than a setting. And the array as printed never closes, because the third entry's tag list ends on the fragment VS Cod with no closing bracket and no closing brace, so it is a shape to copy rather than a file to paste.

A malformed projects.json has one documented way out

The failure mode is stated plainly: be sure that the JSON file is well-formed, otherwise Project Manager will not be able to open it, and an error message should appear. In that case the page tells you to use the Open File button to fix it. Two gaps follow from that wording. The error text itself is not printed on the page, so what you will see when the list stops loading is left to the interface rather than described. And recovery is manual: no backup file, no regenerate command, and no reset entry in the list of five commands, so a hand edit that loses a closing brace costs you the list until you repair it by hand. Since the same file is where new favorites are appended, the editing surface and the write surface are one and the same, which is why the enabled field exists on every entry.

It activates at every startup, and the remote side is a second decision

The activation events contain a single entry, onStartupFinished, so the extension's code runs on every editor launch whether or not you open a project list. The manifest also declares extensionKind as both ui and workspace, and the page then asks you to override that for remote work.

    "remote.extensionKind": {
        "alefragnani.project-manager": [
            "workspace"
        ]
    },

The two scenarios it describes are symmetric. Installed locally it works with nothing to configure, and you can save Container, SSH, WSL or Codespaces folders as favorites, each with its own icon, and selecting one lets VS Code open the remote itself. If you normally live on the remote and want favorites stored there, or repos auto-detected there, the extension has to run on the remote side, and that is what the setting forces. The manifest already permits either side, so the setting is not unlocking anything; it is picking one.

Four side bar views, three of them behind when clauses

The activity bar gets one container titled from a localized string, with the icon at docs/images/project-manager-side-bar.svg. Inside it the visible part of the manifest registers four views: projectsExplorerFavorites with no condition, then projectsExplorerGit behind projectManager.canShowTreeViewGit, projectsExplorerSVN behind projectManager.canShowTreeViewSVN, and projectsExplorerAny behind its own canShowTreeViewAny clause. So the tree only grows when the matching source is present, which matches the page's promise of auto-detecting Git, Mercurial and SVN repositories alongside VS Code folders and any other folder. Worth noting that no Mercurial view id appears in that visible block even though Mercurial is one of the five advertised kinds. The listing behaviour has its own settings: sortList takes Saved, Name, Path or Recent, groupList decides whether the list is grouped by kind, and removeCurrentProjectFromList is false by default.

The keyboard sample stops mid clause, and the build lands in dist

Vim style navigation is offered through a when clause named inProjectManagerList.

    {
        "key": "cmd+j",
        "command": "workbench.action.quickOpenSelectNext",
        "when": "inProjectManagerList && isMac"
    },
    {
        "key": "cmd+shift+j",
        "command": "workbench.action.quickOpenSelectPrevious",
        "when": "inProjectManagerList && isMac"
    },
    {
        "key": "ctrl+j",
        "command": "workbench.action.quickOpenSelectNext",
        "when": "inProjectManagerList && (isWindows || isLinux)"
    },

Each binding maps cmd+j or ctrl+j to workbench.action.quickOpenSelectNext and the shift variant to quickOpenSelectPrevious, with isMac on the first pair and isWindows or isLinux on the second. The page's own sample ends inside the next entry, at the fragment inProjectManage, so the fourth binding is not printed. Around that, the packaging is ordinary: the entry point is ./dist/extension, built through webpack.config.js, and the source sits in src with an api directory, a walkthrough directory that pairs with the Getting Started entry in the change list, a plans directory, a vscode-whats-new directory and a .gitmodules file at the root. Localization is broad rather than deep, with eight package.nls files alongside package.nls.json and an l10n directory, plus a Chinese README.

Editorial conclusion

Use it if you jump between many checkouts and want one list with tags and profiles on top of what VS Code already does. Skip it if your project list is something you would rather generate than hand-maintain, since projects.json is the source of truth and nothing on the page describes regenerating it. Check four things in your own clone. The license is named two ways, GPL-3.0 as the recorded license for the project and SEE LICENSE IN LICENSE.md in the extension manifest, with LICENSE.md as the actual file. The newest release tag is v12.0.1 from November 2020 while the manifest reads 13.1.1, so judge activity by the 2026-09-24 commit rather than by the tag list. The extension activates on every startup, and its own remote guidance asks you to override a manifest that already declares both extension kinds.

Frequently asked questions

Official sources

1. alefragnani/vscode-project-manager on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases