Fixing VS Code Forgetting Recents, Workspace Trust, and GitHub Sign-In on Windows

VS Code, Codex, Codex Computer Use, AI & ML, LLM / By

After a recent VS Code update, several pieces of state stopped persisting between restarts. The symptoms looked unrelated at first, but they turned out to share the same underlying cause.

Observed Problem

The first sign was that recent projects disappeared. The Welcome page showed no recent folders, File > Open Recent showed only a tiny list or nothing, and Ctrl+R did not show the expected long history.

Other state also stopped sticking:

  • Workspace Trust: Folders that had already been trusted prompted again after reopening VS Code.
  • GitHub and Copilot sign-in: VS Code or GitHub Copilot required signing in again after each restart.
  • Windows taskbar recents: Right-clicking the VS Code taskbar icon did not show recent folders or projects.

At first this looked like a VS Code settings issue, profile issue, or cleanup-tool issue. It was not.

Initial Checks

The usual suspects were checked first:

  • VS Code profile selection
  • settings.json
  • workbench.startupEditor
  • window.restoreWindows
  • VS Code recent-history database
  • WSL VS Code server state
  • Workspace Trust configuration
  • GitHub authentication logs
  • Windows Jump List settings

The VS Code recent-history data still existed on disk. That was the key clue. The recent list was not gone; VS Code simply was not able to reliably use the storage location where newer versions expect shared application state to live.

The Real Cause

The root cause was a Windows filesystem permission problem.

Modern VS Code uses a shared state directory under the Windows user profile root:

C:\Users\<user>\.vscode-shared\sharedStorage\

Inside that folder is a SQLite database:

C:\Users\<user>\.vscode-shared\sharedStorage\state.vscdb

This database can hold multiple kinds of VS Code shared state, including:

  • Recently opened paths
  • Workspace Trust state
  • Secret storage entries
  • GitHub authentication state
  • Extension authentication state

VS Code logs showed errors similar to:

EPERM: operation not permitted, mkdir 'C:\Users\<user>\.vscode-shared'

That means VS Code tried to create or use its intended shared-state folder, but Windows denied access.

The important nuance is that many normal user folders were writable, including AppData, Documents, and project folders. But the actual profile root, C:\Users\<user>, did not grant the user enough permission to create .vscode-shared.

VS Code itself was functioning, but its shared persistence layer was partially broken.

Why Multiple Features Broke at Once

This was not three separate bugs. The following features all depended on VS Code being able to read and write shared state:

Recents
Workspace Trust
GitHub authentication
Copilot authentication

Once VS Code could not reliably access .vscode-shared, those features appeared to forget their state between launches. That is why the symptoms felt broad and confusing.

Repairing the Intended VS Code Storage Location

The fix was to repair access to the intended VS Code shared storage location.

First, close all VS Code windows.

Then create the intended directory if it does not exist:

New-Item -ItemType Directory -Force "$env:USERPROFILE\.vscode-shared\sharedStorage"

Then grant the current Windows user full control over .vscode-shared:

$shared = "$env:USERPROFILE\.vscode-shared"
$user = "$env:USERDOMAIN\$env:USERNAME"

icacls $shared /grant "${user}:(OI)(CI)(F)"

The flags mean:

OI = Object inherit
CI = Container inherit
F  = Full control

In plain terms, the user receives full control over the .vscode-shared folder and anything created underneath it. After fixing permissions, reopen VS Code normally.

Verifying the Fix

After reopening VS Code, check the logs or verify that this file exists:

C:\Users\<user>\.vscode-shared\sharedStorage\state.vscdb

A healthy VS Code launch should be able to create or open that database without EPERM errors.

The expected result:

  • The Welcome page shows recent folders again.
  • Ctrl+R shows the full searchable recent list.
  • File > Open Recent shows recent entries again.
  • Workspace Trust remains trusted after restart.
  • GitHub and Copilot authentication persist after restart.

Helpful VS Code Settings

These settings were also useful to make startup behavior predictable:

{
  "workbench.startupEditor": "welcomePage",
  "window.restoreWindows": "none"
}

workbench.startupEditor controls whether VS Code opens the Welcome page.

window.restoreWindows controls whether VS Code restores the last opened project or window.

These settings do not fix the storage problem by themselves, but they make it easier to see whether Recents are working.

Windows Taskbar Recents

There was also a separate Windows Jump List issue. VS Code may log an error like:

customCategoryAccessDeniedError

That affects the Windows taskbar right-click recent list, not VS Code's internal recent list.

The related Windows setting is:

HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
Start_TrackDocs

To enable recent items in Jump Lists:

Set-ItemProperty `
  -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" `
  -Name Start_TrackDocs `
  -Type DWord `
  -Value 1

Then restart Explorer:

Stop-Process -Name explorer -Force
Start-Process explorer.exe

After that, right-clicking the VS Code taskbar icon should show recent projects again.

Using Codex Computer Control to Diagnose and Fix It

A useful part of this troubleshooting process was using the Codex Windows app with local computer control, rather than only guessing from the VS Code UI.

From the Windows app, Codex was able to inspect the actual Windows and VS Code state directly:

$env:APPDATA
$env:USERPROFILE
Get-Process Code
Get-Content "$env:APPDATA\Code\User\settings.json"

It also checked VS Code's SQLite state databases, logs, shortcut launch arguments, Windows registry values, and WSL-side VS Code folders.

That made it possible to compare what the UI showed against what VS Code had actually stored on disk. For example, the UI initially showed no useful recent projects, but the database still contained hundreds of recent entries. That narrowed the issue from "VS Code forgot everything" to "VS Code cannot read or write the state it expects."

The Codex Windows app also helped safely apply the fix:

New-Item -ItemType Directory -Force "$env:USERPROFILE\.vscode-shared\sharedStorage"

$user = "$env:USERDOMAIN\$env:USERNAME"
icacls "$env:USERPROFILE\.vscode-shared" /grant "${user}:(OI)(CI)(F)"

After each change, Codex verified the result by checking:

  • whether VS Code was launched with normal arguments
  • whether .vscode-shared\sharedStorage\state.vscdb existed
  • whether recent entries were present
  • whether Workspace Trust entries were present
  • whether GitHub auth state persisted
  • whether VS Code logs still showed permission errors

This was especially helpful because the visible symptoms were misleading. The Welcome page, Open Recent menu, Workspace Trust prompt, and Copilot sign-in all looked like separate problems. Local inspection showed they shared the same underlying storage failure.

Final Outcome

After repairing access to:

C:\Users\<user>\.vscode-shared

VS Code was able to persist state normally again. The following features recovered:

  • Recent projects
  • Workspace Trust
  • GitHub authentication
  • GitHub Copilot authentication
  • Windows taskbar recent projects

Lessons Learned

When VS Code starts forgetting multiple unrelated things at once, do not only check VS Code settings. Check whether VS Code can write to its state directories.

For modern VS Code on Windows, the important shared-state path is:

C:\Users\<user>\.vscode-shared\sharedStorage\state.vscdb

If that path cannot be created or written due to profile-root permissions, several VS Code features may appear broken even though their individual settings are correct.

The broader lesson is that when an application starts forgetting several unrelated pieces of state, the Codex Windows app can be useful because it can inspect the filesystem, logs, databases, registry, process arguments, and configuration files together instead of treating each UI symptom in isolation.

Related Posts