Solved The Blind Spot: why CMD/PowerShell don't generate Jump Lists (Experimental Data)

Context/Goal
I am currently finalizing a paper on Windows Shell artifact generation and wanted to share some experimental findings regarding the interaction between applications and `shell32.dll`. My goal is to understand why command-line interfaces (CLIs) like `CMD` and `PowerShell` do not generate Jump Lists.

Problem/Observation
Standard file operations performed via `CMD` or `PowerShell` do not result in updates to `AutomaticDestinations` or the `Recent folder`, making them forensically "invisible" to these artifacts.

Experimental Steps

1. Using `ProcMon`, I confirmed that standard file operations (e.g., `mkdir`, `echo`, `New-Item`) executed through `CMD` or `PowerShell` generate zero updates to `AutomaticDestinations` or the `Recent folder`.
2. I wiped all `*.automaticDestinations-ms` files. Creating files via the CLI did not trigger a re-initialization of these files.
3. I manually invoked the Win32 API `SHAddToRecentDocs` within a PowerShell session using the following C# P/Invoke signature:
   
   Code:

   public static extern void SHAddToRecentDocs(uint flags, string path);

Results/Observations
When `SHAddToRecentDocs` was manually invoked, `ProcMon` captured `powershell.exe` interacting with `explorer.exe`. `explorer.exe` then acted as the "clerk" to write the `LNK` and Jump List files.

Conclusion
CLI tools are forensically "invisible" to Jump List and Recent folder artifacts because they lack a static dependency on `shell32.dll` and do not perform the necessary notification required by the Shell. This confirms that the absence of a Jump List entry does not necessarily mean no activity occurred.

Questions for the Community

1. Has anyone observed modern CLI tools (such as `Windows Terminal` or specific 3rd party shells) that do explicitly call the `SHAddToRecentDocs` API?

I am looking forward to any insights or critiques before I submit the final paper.

Welcome. ElevenForum is more of community for Windows enthusiasts and a handful of IT admins, but less visited by security researchers.

From my perspective as a working Windows admin and CMD/PS programmer:

1. I wouldn't be surprised that both shells don't call SHAddToRecentDocs. CMD was mostly written before jump lists were popularized. The only time I would expect to see either a CMD or PS script be added to the jump list is because you clicked on the file from Explorer.

2. CMD has no persistent command or file history. Once you terminate a shell, no (application-based) memory of previous actions are saved.

3. By default, PS has no persistent command or file history. You can configure your profile to save recent command history and reload it upon your next session. However, the command history represents previously executed scripts as "command lines". They're not treated as explicit file objects.

4. PS IDE does remember recently opened files, but that's a native feature. I don't know offhand if your edited files show up on the jump list, but I doubt it.

5. In conclusion, I don't believe CMD or PS are purposely hiding their activity. It's more likely having recent files on the jump list was never a supported design feature. Something like a modern IDE (ie. Visual Studio) would be different.

Windows PowerShell 5.1 does have the built-in PSReadLine history already enabled by default.
Launching powershell.exe -NoProfile does not disable the PSReadLine history on systems that have it already enabled by default.
However, running a .ps1 script file does not save the file's content in the history. For that, you'd have to copy-paste the script file content directly into the PowerShell console.

Thank you, guys! That helped a lot.