GitHub Repo
Ollama v0.40.1 Includes Windows Migration Fix, Repairs Existing Model Manifest Symlinks on Read
Ollama released v0.40.1 on October 7, switching Windows model manifests to regular files and adding an on-read repair mechanism for existing symlinks. This gives community reports of previously unusable model names an official release path, though recovery across different Windows environments remains to be verified.
Ollama’s Windows model migration issue now has an official fix. Released on October 7, v0.40.1 includes a change to “avoid symlinks on Windows”; the related PR #18852 has been merged, and the original issue #18847 has been closed. Unlike the earlier community reproductions, the fix is now in an installable release, so affected deployments can begin verifying recovery. Release notes
The original case occurred on Windows 11: after automatically updating from 0.35.1 to 0.40.0, the user could no longer use the existing qwen3.5:9b through the CLI or API. The migration process wrote the named manifest as a symlink to a blob, which Windows then refused to open, reporting an untrusted mount point. As a result, /api/show and /api/chat returned 500 errors. The reporter could still run the model under another internal name, suggesting that the weights were available and the failure was confined to reading the manifest associated with the model name. Issue reproduction
The fix addresses both new writes and existing data. On Windows, creating a named manifest now uses a file-copy path; for existing symlinks, Ollama repairs them on read using a verified blob. The change also adjusts how the manifest store lock is used, preventing cleanup of unreferenced data from acquiring the same lock again. Because repair happens during access, engineering teams should still confirm that commonly used model names resolve correctly. Fix details
For local agents and desktop AI applications, a name-resolution failure can block subsequent inference even when the weights remain on disk. The official Windows documentation explains that Ollama runs in the background and provides a local API, and that installation does not require administrator privileges. When troubleshooting, compare server.log, upgrade.log, and the actual model directory, and account for deployments with a custom OLLAMA_MODELS setting. Windows documentation
What is confirmed so far is that the fix has been merged and included in an official release; public information does not yet provide recovery statistics across Windows configurations. The original reporter’s explanation of the conditions that trigger Developer Mode remains speculative. After upgrading, check whether CLI queries using the original names, API calls, and the model list are consistent again, and report any remaining errors upstream along with the version and logs.