ComfyUI extra_model_paths.yaml not working? Here’s the fix
ComfyUI not finding checkpoints, LoRAs, VAEs, or upscalers? Here’s how to repair extra_model_paths.yaml and confirm it works.

extra_model_paths.yaml errors by checking the right config file, YAML structure, folder keys, logs, and Desktop path issues. © Popular AIIf ComfyUI extra_model_paths.yaml is not working, do not start by reinstalling ComfyUI or moving hundreds of gigabytes of models. The usual cause is much simpler: the file is in the wrong place, the YAML structure is wrong, the Desktop app is reading a different config file, or a node is looking for a more specific folder key than the one you mapped.
The fix is to confirm which config file ComfyUI is actually loading, use the official nested YAML format, map each model type to the exact folder key ComfyUI expects, then restart and check the logs for Adding extra search path.
Quick answer
The fastest fix is:
Find the config file ComfyUI is actually using.
Back it up.
Make sure the file has a top-level profile name like
comfyui:.Put
base_pathand folder mappings under that profile.Use exact folder keys, such as
checkpoints,loras,vae,text_encoders,diffusion_models,upscale_models, andlatent_upscale_models.Restart ComfyUI.
Check the startup log for
Adding extra search path.
ComfyUI’s own example says to rename extra_model_paths.yaml.example to extra_model_paths.yaml and edit it to set model search paths. The same example also shows that base_path belongs under a named section, not at the top level by itself in the official sample file.
What this error means
ComfyUI does not simply scan every model file on your drive. It uses folder keys to decide where each loader should look. A checkpoint loader checks checkpoints. A LoRA loader checks loras. A latent upscaler may check latent_upscale_models.
That detail is what trips people up. A model can be on the right disk, inside the right general model library, and still be invisible to the node that needs it. The file has to sit in a path registered under the folder key that the loader actually uses.
The current ComfyUI path loader reads the YAML file, loops through each top-level config section, pulls settings such as base_path and is_default, then registers the mapped folders through folder_paths.add_model_folder_path inside utils/extra_config.py. If the YAML shape is wrong, ComfyUI can fail at startup, ignore the path you expected, or leave a node unable to find the model.
Common causes
The most common causes are:
The file is still named
extra_model_paths.yaml.example.The file is in the wrong folder.
ComfyUI Desktop is using
extra_models_config.yamlfrom an app data directory instead of the file you edited.The YAML is missing a top-level profile name.
The indentation is wrong.
You mapped a model folder under the wrong key.
You used
upscale_modelswhen the node wantslatent_upscale_models.The model download UI saved the file to your browser downloads folder instead of your configured server path.
A custom node or workflow is using a folder key that your config does not define.
More on ComfyUI troubleshooting:
Fix 1: Confirm which config file ComfyUI is loading
For the Windows portable or manual install, the normal path is:
ComfyUI/extra_model_paths.yamlThe official ComfyUI README says that, in the standalone Windows build, users can find the config file in the ComfyUI directory, rename it to extra_model_paths.yaml, and edit it to set model search paths for sharing models between UIs.
For ComfyUI Desktop, do not assume it is reading the same file. In one Desktop issue report, the launch arguments showed ComfyUI being started with an explicit --extra-model-paths-config value pointing to:
C:\Users\[name]\AppData\Roaming\ComfyUI\extra_models_config.yamlThat path was visible in the user’s startup arguments in ComfyUI issue #11242. The same report involved a latent upscale loader error where ComfyUI was looking for a model in latent_upscale_models, which is a useful reminder that Desktop path issues and folder-key issues can overlap.
Look in your startup log for something like:
--extra-model-paths-config C:\Users\...\extra_models_config.yamlIf that appears, edit that file instead of guessing. This is especially important after Desktop updates, because the app wrapper can control the launch arguments and user directory.
Fix 2: Use the correct YAML structure
A common broken version looks like this:
base_path: D:/AI/
checkpoints: models/checkpoints/
loras: models/loras/
vae: models/vae/That looks reasonable, but it is wrong for ComfyUI’s expected config shape. A user reported this kind of top-level structure causing:
TypeError: string indices must be integers, not 'str'The public bug report shows ComfyUI failing while loading extra_model_paths.yaml because the config was shaped like direct key-value pairs instead of a nested section in issue #11404.
Use this structure instead:
comfyui:
base_path: D:/AI/
is_default: true
checkpoints: models/checkpoints/
loras: models/loras/
vae: models/vae/
text_encoders: |
models/text_encoders/
models/clip/
diffusion_models: |
models/diffusion_models/
models/unet/
upscale_models: models/upscale_models/
latent_upscale_models: models/latent_upscale_models/
clip_vision: models/clip_vision/
controlnet: models/controlnet/
embeddings: models/embeddings/
audio_encoders: models/audio_encoders/
model_patches: models/model_patches/The top-level name can be comfyui, a1111, my_models, or another label. The important part is that base_path and the folder keys sit under that label.
That nesting is what lets ComfyUI treat the first level as a profile, then read the folder mappings inside it. Without that profile layer, values like base_path can be treated like sections, which leads to confusing startup errors.
Fix 3: Use exact folder keys
ComfyUI has added and renamed folder conventions over time. The official example currently includes text_encoders, while still noting the legacy models/clip/ location. It also includes diffusion_models, with models/unet listed as a supported older location in the example config.
That means this is safer:
text_encoders: |
models/text_encoders/
models/clip/And this is safer:
diffusion_models: |
models/diffusion_models/
models/unet/Do not rely on old folder names alone when a newer workflow expects the newer key. Keeping both the current and legacy folder paths under the same key can make older workflows and newer workflows easier to run from one shared model library.
This also helps when a workflow was downloaded from someone else’s setup. Their node may expect a newer folder key even if your existing model library still uses an older folder name.
Fix 4: Separate latent_upscale_models from upscale_models
This one is easy to miss.
A user reported that the LTX-2 latent upscaler was not being found even though their logs showed ComfyUI adding model paths. The fix in the issue comments was to stop placing the latent upscaler folder under upscale_models and define a separate latent_upscale_models key instead in issue #12004.
Use this:
upscale_models: models/upscale_models/
latent_upscale_models: models/latent_upscale_models/Do not use this for latent upscalers:
upscale_models: |
models/upscale_models/
models/latent_upscale_models/That may register both folders as regular upscale model paths, but a node that calls latent_upscale_models still will not find what it needs.
The key lesson is simple: a folder path can be valid and still be registered under the wrong category. When a loader says a model is missing, check the exact folder name in the error message. That folder name is usually the key you need in extra_model_paths.yaml.
Fix 5: Use stable path formatting
On Windows, use forward slashes in YAML paths. They work in Python paths and avoid accidental escape problems.
Use this:
base_path: D:/AI/Avoid this unless you know exactly how YAML is parsing it:
base_path: "D:\AI\"Also check:
Use spaces, not tabs.
Keep indentation consistent.
Add trailing slashes for readability.
Do not put comments after paths inside multi-line blocks.
Make sure every mapped folder exists.
Make sure the model file extension is supported by that loader.
YAML is strict about indentation, and path typos are easy to miss. If a folder is supposed to be relative to base_path, confirm that the combined path exists exactly as written. For example, base_path: D:/AI/ plus checkpoints: models/checkpoints/ points to D:/AI/models/checkpoints/.
Fix 6: Restart and check the logs
After editing the config, restart ComfyUI completely. Browser refresh is not enough.
For Windows portable, run from the portable folder:
.\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-buildFor a manual install:
python main.pyDuring startup, look for lines like:
Adding extra search path checkpoints D:\AI\models\checkpoints
Adding extra search path loras D:\AI\models\loras
Adding extra search path latent_upscale_models D:\AI\models\latent_upscale_modelsIf those lines do not appear, ComfyUI is not reading your file, the YAML is invalid, or you edited the wrong config.
Those startup lines are the most useful test because they prove ComfyUI loaded the config and registered the folder key. A model missing from the dropdown after those lines appear usually points to a category mismatch, unsupported file type, filename issue, or node-specific loader behavior.
Fix 7: Rule out custom nodes only after the path file is correct
If the config file is valid and the logs show the right paths, then test without custom nodes. ComfyUI’s official troubleshooting guide recommends starting ComfyUI with:
python main.py --disable-all-custom-nodesFor the Windows portable build, the docs show this form:
.\python_embeded\python.exe -s ComfyUI\main.py --disable-all-custom-nodesComfyUI’s documentation says that if the issue disappears with custom nodes disabled, a custom node is probably involved. If the issue persists, it is likely not a custom node issue according to the troubleshooting guide.
This step belongs after the config check, not before it. Otherwise, you can waste time blaming a custom node when the real problem is a missing folder key or the Desktop app reading a different YAML file.
Fix 8: Do not trust the missing-model download button to place files correctly
If a workflow says models are missing and offers a download button, check where the file actually went.
An open ComfyUI issue reports that the Workflow Overview missing-models panel can trigger a browser download into the OS downloads folder instead of saving the model to the server-side folder configured in extra_model_paths.yaml in issue #13676.
The workaround from that issue is simple: copy the URL and download the file directly into the correct model folder.
Example:
wget -P /mnt/ai/models/diffusion_models "MODEL_URL_HERE"On Windows, download manually into the mapped folder, such as:
D:\AI\models\diffusion_modelsThen restart ComfyUI or refresh the model list if the node supports it.
This matters most for remote setups, network storage, NAS paths, and headless servers. In those cases, a browser download may land on your local machine while ComfyUI is running somewhere else.
Fix 9: Be careful with ComfyUI Desktop updates
ComfyUI Desktop and ComfyUI Core use different version numbers. As of June 6, 2026, ComfyUI Core’s latest GitHub release page showed v0.24.0 dated June 3, 2026 on the core releases page, while ComfyUI Desktop’s releases page showed v0.9.4 dated May 28, 2026 and bundling ComfyUI v0.22.3 on the Desktop releases page.
That matters because a Desktop update can change the bundled core, launch arguments, user directory, base directory, or config location.
ComfyUI’s frontend team also acknowledged in March 2026 that a number of releases had regressions, with workflows breaking and previously working behavior failing, then announced a stability-focused pause and stricter release gates in issue #10585. That does not prove every extra_model_paths.yaml issue is caused by a regression, but it does make one habit worth keeping: always save a copy of a working config before updating.
A backed-up config is especially useful if a Desktop update changes where the app looks for extra_models_config.yaml. When a setup breaks after an update, compare the new startup log with the last known-good startup log before moving any model folders.
Working example for a shared model folder
Use this if your models live in D:\AI\models:
shared_ai_models:
base_path: D:/AI/
is_default: true
checkpoints: models/checkpoints/
configs: models/configs/
vae: models/vae/
loras: models/loras/
embeddings: models/embeddings/
clip_vision: models/clip_vision/
controlnet: models/controlnet/
text_encoders: |
models/text_encoders/
models/clip/
diffusion_models: |
models/diffusion_models/
models/unet/
upscale_models: models/upscale_models/
latent_upscale_models: models/latent_upscale_models/
audio_encoders: models/audio_encoders/
model_patches: models/model_patches/Folder layout:
D:\AI
└── models
├── checkpoints
├── configs
├── vae
├── loras
├── embeddings
├── clip_vision
├── controlnet
├── text_encoders
├── clip
├── diffusion_models
├── unet
├── upscale_models
├── latent_upscale_models
├── audio_encoders
└── model_patchesThis layout keeps the model library outside the ComfyUI install folder while still giving ComfyUI a clean map for each loader type. It also makes upgrades less painful because the app can be replaced without moving your checkpoints, LoRAs, VAEs, diffusion models, and upscalers.
How to confirm it is fixed
Your setup is fixed when all three are true:
ComfyUI starts without a YAML traceback.
The startup log shows
Adding extra search pathfor the folders you mapped.The relevant loader node can see the model in its dropdown.
If the log shows the path but the model still does not appear, check whether the model is in the right folder key for that exact node.
A Load Checkpoint node will not care about a model stored only under diffusion_models. A latent upscaler will not care about a model stored only under upscale_models. The folder key has to match the node.
When in doubt, read the error message literally. If it says the model is missing from latent_upscale_models, add or fix the latent_upscale_models mapping. If it says a checkpoint is missing, check checkpoints. The log and the loader name usually tell you where to look next.

Privacy, security, and local-control notes
Local ComfyUI setups are valuable because they keep model files, workflows, and outputs on hardware you control. The ComfyUI README says the core can work fully offline and will not download anything unless the user chooses to, while optional API nodes can access paid external providers and can be disabled with --disable-api-nodes in the ComfyUI README.
For production or client work:
Keep a backup of
extra_model_paths.yaml.Keep a copy outside the ComfyUI install folder.
Avoid editing
folder_paths.pyunless you are debugging or developing.Prefer config files over source patches.
Save a known-good ComfyUI version before updating.
Keep your models in a dedicated folder outside app-managed directories.
Disable API nodes if you want to avoid accidental hosted-model calls.
A clean model path setup is also easier to audit. If every model type has a clear folder, it is much simpler to back up configs, sync model libraries between machines, and recover after a failed app update.
FAQ
Where should extra_model_paths.yaml go?
For portable and manual installs, put it in the main ComfyUI folder. For ComfyUI Desktop, check the startup log for
--extra-model-paths-config, because Desktop may point to a different config file.
Why does ComfyUI say TypeError: string indices must be integers, not 'str'?
The most likely cause is invalid YAML structure. Put
base_pathand the folder keys under a top-level profile name likecomfyui:.
Why does the model appear in one node but not another?
Different nodes search different folder keys. A regular upscaler and a latent upscaler can look in different registered folders. Put latent upscalers under
latent_upscale_models.
Can I use symlinks instead?
Yes, symlinks can work, but they add another failure point. Use
extra_model_paths.yamlfirst if you want a cleaner setup that survives moving or sharing model folders.
Should I edit folder_paths.py?
Usually no. Use
extra_model_paths.yamlunless you are debugging ComfyUI itself. Source edits can be overwritten by updates and make future troubleshooting harder.
Why did this break after updating ComfyUI Desktop?
Desktop releases can change bundled ComfyUI versions and launch arguments. Check the Desktop release notes, check which config file is being passed at startup, and compare your current config with your last working copy.
Final recommendation
Fix extra_model_paths.yaml at the config level first. Do not move your whole model library and do not patch ComfyUI source unless you have confirmed a real core bug.
The safest working setup is a dedicated model folder, a backed-up YAML file, exact folder keys, and a startup-log check after every update. That keeps your ComfyUI workflow local, portable, and easier to recover when a desktop wrapper or core update changes behavior.
Explore more from Popular AI:
Start here | Local AI | Fixes & guides | Builds & gear | Popular AI podcast



