[HalRiveria-Bot]

What was wrong

Every program the kit started ran in the PowerShell process's working directory. cd and Set-Location never change that folder. So after cd D:\work at the prompt and then .\script.ps1, every program started in whatever folder the console had opened in: the home folder, or System32 for an admin window. Scripts that Set-Location themselves hit the same thing.

• Relative paths in a program's arguments pointed at the wrong folder. The program could fail to find its input, or write its output somewhere unexpected and still report success.
• A FilePath like .\tool.exe couldn't be started at all, even though & .\tool.exe works in PowerShell.
• A relative WorkingDirectory was resolved against the wrong folder. One on a PowerShell drive (~, or a drive made with New-PSDrive) failed outright.

This affects every entry point: the batch, the dispatcher, Invoke-PkProcessWithTimeout and Start-PkProcess. Reproduced on Windows PowerShell 5.1 and PowerShell 7.

What changed

Start-PkProcess, which every entry point uses, now does the following:

• Default folder: programs start in the caller's current file-system location.
  • On a New-PSDrive drive, that's the real folder behind the drive.
  • When the current location isn't on disk (HKLM:\, say), it's the last file-system location.
  • If the current folder has been deleted, it falls back to the old default.
• Paths read as PowerShell reads them: a relative WorkingDirectory, and a FilePath with a folder in it, are resolved the way PowerShell resolves paths. That includes ~ and New-PSDrive drives.
• Unchanged: a bare name like cjxl.exe is still found the way Windows finds programs, and an explicit absolute WorkingDirectory behaves as before.
• Clearer error: when a program with a relative path can't be started, the error names the full path that was tried.
• Docs: the README and the Start-PkProcess / Invoke-PkProcessWithTimeout help say what the default is. The README also notes that a .bat/.cmd program can't run with a network share (\server\share) as its working folder, because cmd.exe falls back to C:\Windows there.

Compatibility: scripts that never change location behave exactly as before. A script that changes location and works today must already pass absolute paths, so it's unaffected too. The one case that gets worse is a .bat/.cmd program run while the current location is a network share.

Testing

• New harness section W, 11 checks, run in a temp folder that isn't the process's working directory:
  • the default folder for each of the four entry points;
  • .\pk-wd.cmd;
  • a relative WorkingDirectory;
  • a New-PSDrive location, plus FilePath and WorkingDirectory on that drive;
  • ~;
  • a registry location;
  • a deleted current folder;
  • an explicit WorkingDirectory;
  • the error message naming the full path.
• Against the kit on main: 8 of the new checks fail (8 FAILED, 249 passed). The other three (the precondition, the deleted folder and the explicit WorkingDirectory) are guards that pass on both.
• With the change: ALL PASSED (257 assertions) on 5.1 and 7.

🤖 Generated with Claude Code