[BUG] Claude Desktop Filesystem extension intermittently reverts to a stale allowed-directory list mid-session (Windows, WSL UNC paths)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The Filesystem extension's running server and its saved configuration repeatedly fall out of sync. The server enforces an allowed-directory list from before the most recent config change, while the settings UI shows the current one. Nothing in the UI indicates the divergence.

The decisive evidence: the server's own refusal message enumerates the list it is enforcing, and that enumeration is provably older than the saved config. In our case the enforced list still contained a narrower, previously-removed path (...\.claude\projects\<one-project-dir>) and lacked the parent directory (...\.claude\projects) that had been saved days earlier and was visibly present in the settings UI.

Toggling the extension off/on restores the correct list — but it does not stay fixed. The stale list returned twice more over the following 18 hours with no config change in between (three occurrences total). So this is not simply a missed reload at config-write time: the enforcing process also reverts to a stale list spontaneously, which suggests it is being recycled and re-reading a cached/older config, or that calls are routed to more than one server instance with different loaded configs.

What Should Happen?

The enforcing process should read the allowed-directory list on change and keep it across process recycles. A config write should not be able to complete without the running server picking it up and holding it. If a reload cannot be guaranteed, the refusal should say so — it already prints the enforced list, so adding "this list was loaded at <time>; the saved configuration changed at <time> — toggle the extension to reload" would turn an undiagnosable failure into a one-line fix.

Error Messages/Logs

Access denied - path outside allowed directories: \\wsl.localhost\<distro>\home\<user>\.claude\projects not in [<enumerated list omitting that path, matching a pre-change configuration>]

Steps to Reproduce

1. In Claude Desktop, add a new allowed directory in the Filesystem extension settings and save (here: a \\wsl.localhost\<distro>\... path).
2. Call a filesystem tool against a path under it — may work initially.
3. Continue a long session (hours), periodically calling list_allowed_directories.
4. Observe it eventually return a list predating the config change; reads under the saved directory are refused, and the refusal enumerates the stale list.
5. Toggle the extension off and on — the correct list returns.
6. Repeat steps 3-5; the stale list recurs.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A — this is Claude Desktop 1.26832.0 (Electron 42.7.0, Node 24.18.0), not the CLI.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

This is a Claude Desktop first-party Filesystem extension issue, not the Claude Code CLI — filing here per precedent (#58765, #27719, #21320). Allowed directories span Windows paths and WSL2 UNC paths (\\wsl.localhost\<distro>\...). Paths are redacted; the shape is what matters. Observed three times across 2026-09-03 evening to 2026-09-04 morning on the same machine with no configuration changes between occurrences.