File Explorer wont expand to folder

frogSushi · Apr 13, 2026

To summarize, the python shortcut patcher I posted yesterday fixes tree expansion when navigating within an existing Explorer window, but when you open a shortcut from the desktop or the taskbar, Explorer spawns a new window and the navigation pane defaults to Home instead of syncing to the target folder.

The fix is a small AutoHotkey v2 script that runs silently in the background. It hooks into Windows' own event system and reacts instantly whenever a new File Explorer window appears, automatically triggering the tree sync — no polling, no performance impact.
You can adjust the SEND_DELAY constant to your liking. On my machine, even 100ms seems to work fine.

Note: If you don't patch the shortcut with the shortcut patcher, the tree will still expand, but it will anchor to the parent library node (Documents, Downloads, Pictures, etc.) if there is one, rather than tracing the actual filesystem path — and the navigation pane won't follow when you navigate from there. This may or may not be an issue depending on your setup and expectations.

To run it automatically at Windows startup, two options:

Add it to the startup folder
Create a scheduled task set to trigger at logon

dacrone · Apr 13, 2026

you dont need to create all new shortcuts and use a py and ahk together. here is an ahk that will expand the current directory and collapse all siblings. it still has shortcomings at the moment though:

1) if you open a folder located on the desktop (this does not apply if it is a shortcut to a folder in, example, downloads) it does not expand to that folder in the nav pane automatically.
2) if you go back to This PC, the most recently browsed sibling still stays expanded (ie - Pictures > This PC, Pictures will stay expanded in the nav pane)
3) only the first tab (in tabbed explorer) expands in the nav pane

i'll get it functional before too long.

Code:

#Persistent
SetTimer, SyncExplorerTree, 200
global LastPath := ""

TVM_GETNEXTITEM := 0x110A
TVGN_ROOT       := 0x0000
TVGN_PARENT     := 0x0003
TVGN_CHILD      := 0x0004
TVGN_NEXT       := 0x0001
TVGN_CARET      := 0x0009
TVM_EXPAND      := 0x1102
TVE_COLLAPSE    := 0x0001
TVE_EXPAND      := 0x0002

NormalizePath(p) {
    p := RegExReplace(p, "^file:///", "")
    p := StrReplace(p, "/", "\")
    p := Trim(p, "\")
    StringLower, p, p
    return p
}

SyncExplorerTree:
; -----------------------------------------
; Only run when there is exactly ONE Explorer window/tab
; -----------------------------------------
explorerCount := 0
for w in ComObjCreate("Shell.Application").Windows
{
    try
    {
        if InStr(w.FullName, "explorer.exe")
            explorerCount++
    }
}
if (explorerCount != 1)
    return

; -----------------------------------------
; Normal logic, but now only with a single Explorer instance
; -----------------------------------------
for window in ComObjCreate("Shell.Application").Windows
{
    try
    {
        if !InStr(window.FullName, "explorer.exe")
            continue

        CurrentPath := window.LocationURL
        NCurrent := NormalizePath(CurrentPath)
        NLast    := NormalizePath(LastPath)

        if (NCurrent = NLast)
            continue

        hwnd := window.HWND
        ControlGet, hTV, Hwnd,, SysTreeView321, ahk_id %hwnd%
        if !hTV
            continue

        ; -----------------------------------------
        ; COLLAPSE CHILDREN OF TOP-LEVEL CATEGORIES
        ; -----------------------------------------
        SendMessage, %TVM_GETNEXTITEM%, %TVGN_ROOT%, 0,, ahk_id %hTV%
        hRoot := ErrorLevel

        if (hRoot)
        {
            SendMessage, %TVM_GETNEXTITEM%, %TVGN_CHILD%, %hRoot%,, ahk_id %hTV%
            hChild := ErrorLevel

            Loop
            {
                if (!hChild)
                    break

                ; Collapse only the FIRST level under each top-level node
                SendMessage, %TVM_GETNEXTITEM%, %TVGN_CHILD%, %hChild%,, ahk_id %hTV%
                hSub := ErrorLevel

                if (hSub)
                    SendMessage, %TVM_EXPAND%, %TVE_COLLAPSE%, %hSub%,, ahk_id %hTV%

                SendMessage, %TVM_GETNEXTITEM%, %TVGN_NEXT%, %hChild%,, ahk_id %hTV%
                hChild := ErrorLevel
            }
        }

        ; -----------------------------------------
        ; EXPAND CURRENT FOLDER
        ; -----------------------------------------
        SendMessage, %TVM_GETNEXTITEM%, %TVGN_CARET%, 0,, ahk_id %hTV%
        hSel := ErrorLevel

        if (hSel)
            SendMessage, %TVM_EXPAND%, %TVE_EXPAND%, %hSel%,, ahk_id %hTV%

        ; -----------------------------------------
        ; COLLAPSE SIBLINGS OF CURRENT FOLDER
        ; -----------------------------------------
        SendMessage, %TVM_GETNEXTITEM%, %TVGN_PARENT%, %hSel%,, ahk_id %hTV%
        hParent := ErrorLevel

        if (hParent)
        {
            SendMessage, %TVM_GETNEXTITEM%, %TVGN_CHILD%, %hParent%,, ahk_id %hTV%
            hChild := ErrorLevel

            Loop
            {
                if (!hChild)
                    break

                if (hChild != hSel)
                    SendMessage, %TVM_EXPAND%, %TVE_COLLAPSE%, %hChild%,, ahk_id %hTV%

                SendMessage, %TVM_GETNEXTITEM%, %TVGN_NEXT%, %hChild%,, ahk_id %hTV%
                hChild := ErrorLevel
            }
        }

        LastPath := CurrentPath
    }
}
return

frogSushi · Apr 14, 2026

@dacrone OK, I see what you are trying to achieve! It's interesting, but it's on a whole different level (much more ambitious) and it uses polling — it modifies File Explorer's behavior entirely. Personally, I wouldn't want my Explorer to work like that, but that's just me!

There are actually several different issues addressed in this thread:

(1) The fact that Windows 11 shortcuts to folders are "broken" and do not trigger navigation pane expansion properly when the target folder is nested in a library (Documents, Downloads, Pictures, etc.). And even if you force expansion (Ctrl+Shift+E), it creates an odd additional tree anchored at the library's root in the navigation pane, which doesn't follow when you navigate from there.

That's what my Python patch fixes. Your PowerShell script doesn't patch the exact same bytes, but I tested it and it works too. Thank you for writing that script — it's easier to run for people who don't have Python!

Both scripts set bits in the LinkFlags field that are not documented in the MS-SHLLINK spec so I can't really explain why they work, only that they do. Maybe we are just breaking the LinkFlags, causing Windows 11 File Explorer to fall back to a legacy code path that handles the shortcut the "old way" — i.e. the Windows 10 behavior — rather than the new shell namespace routing that breaks tree expansion.

(2) The fact that launching a shortcut to a folder from outside File Explorer (from the desktop or the taskbar, for example) doesn't trigger expansion to that folder. This is what the AutoHotkey v2 script from my previous message fixes. It simply sends Ctrl+Shift+E when a new explorer.exe window opens.

(3) There may be other more specific situations mentioned in this thread — I'm not sure, but I don't think those are related to standard Windows 11 shortcuts.

LesFerch · Apr 14, 2026

@frogSushi I'm still not seeing any difference between a patched and unpatched shortcut. I made a shortcut to a subfolder within Downloads. I placed the shortcut in C:\Test and made a patched version also in C:\Test using your script. The two shortcuts behave the same. That is, I get no tree expansion unless both "Expand to current folder" and "Show all folders" are checked.

frogSushi · Apr 14, 2026

LesFerch said:
@frogSushi I'm still not seeing any difference between a patched and unpatched shortcut. I made a shortcut to a subfolder within Downloads. I placed the shortcut in C:\Test and made a patched version also in C:\Test using your script. The two shortcuts behave the same. That is, I get no tree expansion unless both "Expand to current folder" and "Show all folders" are checked.

@LesFerch You need the option "Expand to open folder" checked for anything to work, but not the "Show all folders" option.

But I did some more testing and I think I understand what is happening to you. I can reproduce your issue if I create the original shortcut from within the library, and not from the actual full path of the target folder (from the hard drive root). It seems that, if you create the shortcut from within the library, it is permanently registered as a library folder and the patch won't help.

However if you really start from C: then navigate to > User > [user_name] > Downloads > Your folder (adapt to the actual location of your folder) and create the shortcut from there, then patch it, then it should work. At least it does on my machine.

That is some crazy Windows s@#t for sure.

But we are going to beat it! At least, I hope so. Let me know!

LesFerch · Apr 14, 2026

frogSushi said:
@LesFerch I can reproduce your issue if I create the original shortcut from the library, and not from the actual full path of the target folder (from the hard drive root).

That's exactly what I did. I'll retest with a shortcut created from the full path.

frogSushi · Apr 14, 2026

LesFerch said:
That's exactly what I did. I'll retest with a shortcut created from the full path.

Fingers crossed. On my machine, it does work. I re-tested 3 times on different library folders and the difference between shortcut created from within the library / shortcut created after full path navigation is reproducible.
But it sill requires the patch. If you don't patch, it won't expand in either case.

dacrone · Apr 14, 2026

@LesFerch - save the Fix-ExplorerShortcut.ps1

From This PC - drag Downloads to your desktop to make a shortcut (I assume the name will be Downloads - Shortcut)

Move Downloads - Shortcut to C:\Test\

Open powershell as admin in the same dir as the
Fix-ExplorerShortcut.ps1
and run:

Code:

.\Fix-ExplorerShortcut.ps1 `
    -TargetPath "C:\Test\Downloads - Shortcut.lnk" `
    -ShortcutPath "C:\Test\Downloads.lnk"

Does C:\Test\Downloads.lnk expand when launched?

glasskuter · Apr 14, 2026

LOL when reading this thread. We are all so different in what we want and how we operate. I've always hated using libraries so never do and I nearly went crazy with 11 expanding folders in the left navigation pane when I would open a drive or folder on the right. Brink's tutorial to stop it saved my sanity. (along with some of his others)
I'm such a simple user compared to some of you....and am not too proud to admit it. Could it be because I'm so old???

dacrone · Apr 14, 2026

glasskuter said:
LOL when reading this thread. We are all so different in what we want and how we operate. I've always hated using libraries so never do and I nearly went crazy with 11 expanding folders in the left navigation pane when I would open a drive or folder on the right. Brink's tutorial to stop it saved my sanity. (along with some of his others)
I'm such a simple user compared to some of you....and am not too proud to admit it. Could it be because I'm so old???

I hate expanding nav pane trees as well. I only work on this because it’s been an ongoing issue for years.

frogSushi · Apr 14, 2026

@glasskuter

Haha! Yes, that’s funny! We all have very different habits and ways of working.

I honestly can’t imagine using File Explorer any other way. I never work within a single folder, and I constantly need access across the file tree, sometimes between branches that are far apart. I tried getting used to the path bar, but that only allows linear navigation toward the root, which is really not sufficient for me. I even keep 2 or 3 File Explorer windows open all the time when I work (2 is really the minimum).
Clicking once in a while to collapse a branch I no longer need is nothing compared to having to click 10 times repeatedly just to move between folders. In fact, I don’t even see the point of the navigation pane if it doesn’t expand.

And you’re right, libraries are a big part of the problem. If you don’t use them at all, including Documents, then manually expanding folders in the navigation pane while accessing files in the main area might be acceptable, I guess. Still, I find it less convenient, since it creates an inconsistency between navigating from the main pane and navigating from the tree. Without automatic expansion, the navigation pane no longer reflects where you actually are, which makes the whole system less usable.

But when you’re inside a library, there’s no expansion at all in the navigation pane anymore, and File Explorer forces you into libraries via shortcuts even if you don’t want to navigate from there. That’s actually what I patched (or probably broke, to be honest).

Anyway, it’s fine that everyone has their own way of working. But here, we have an option called “Expand to open folder”, and the fact that it doesn’t work reliably in this context is a bug. The information needed to expand the tree is already available in the shortcut, but Explorer doesn’t consistently use it. It should be possible to make it rely on the full shell path (PIDL) whenever this option is enabled, instead of sometimes falling back to a simplified resolution.

The simplest solution would probably be not to use libraries at all, like you do. Just leave them as they are and never store anything in them. But many applications default to Documents, so it’s also convenient to actually use that folder.

Another approach would be to keep only shortcuts inside library folders, pointing to non-library locations where your actual files are stored.
In my case, I do have shortcuts in Documents, but it’s also the root folder for most of the files I use daily, except for media (which are rooted in their respective library folders for the same reason). However, my libraries are not nested under Users. I’m the only user on my PC, so I moved them closer to the drive root to reduce path length. That may also be one reason why I want them to expand: I don’t have two unnecessary levels of depth (C:\Users\[user_name]) cluttering the tree.

It also feels good to regain some control over your machine. Nowadays, the tools we use tend to dictate how users should interact with them. That’s true for most commercial devices, apps, and operating systems. But a good craftsman adapts his tools to his needs and workflow, not the other way around. So getting your system to behave the way you want (which may differ from one user to the other) feels like a small victory against the Matrix.

File Explorer wont expand to folder

New member

Attachments

My Computer

Well-known member

My Computer

New member

My Computer

Well-known member

My Computer

New member

My Computer

Well-known member

My Computer

New member

My Computer

Well-known member

My Computer

aka Mama Glass

My Computers

Well-known member

My Computer

New member

My Computer

Similar threads