[Ken Kuang (sykuang)]

Summary

• Add native PowerShell hook and terminal launchers that reuse the existing Python bootstrap, honor TE_PYTHON, preserve UTF-8 input, and prefer interpreters outside WindowsApps.
• Route Copilot's Windows hooks and all seven slash commands through PowerShell while keeping the existing Unix commands.
• Maintain both stable bin/te and bin/te.ps1 launchers on Windows.

Bootstrap fix

Creating the stable launcher only at SessionStart left an already-open session without te.ps1. Slash commands then failed with CommandNotFoundException. Prompt hooks now create or repair the launchers before the command runs, and launcher-write errors are recorded in errors.log.

The regression executes the actual PowerShell blocks from the slash-command files after a prompt hook without a preceding session-start event. It failed with the reported missing-launcher error in both Windows PowerShell 5.1 and PowerShell 7 before the fix, and passes afterward.

Validation

• python -m pytest tests\test_plugin_package.py tests\test_live_core.py tests\test_live_safety.py tests\test_hook_queue.py -q --tb=short
• Native checks cover paths containing spaces, apostrophes, and non-ASCII characters; redirected and piped hook input; command arguments and exit codes; missing Python; and WindowsApps discovery.
• Exercised Copilot's native hook routing against a localhost model stand-in, without an external model call.
• Repaired the missing live launcher using the existing helper and successfully reran the original stable-path toolprune refresh-catalog command.

[Muhammad Abdullah Butt (1AbdullahButt)]

I compared te.ps1 with the te and te-hook shell launchers at the PR head. They pick an interpreter in the same order: TE_PYTHON, python3, python, py, preferring one outside WindowsApps and probing the alias last. Both use py -3 and PYTHONUTF8=1, and both fail open with {} and an errors.log line when there is no Python. $OutputEncoding is a BOM-less UTF8Encoding, so the payload piped to Python doesn't start with a BOM. In ensure_launcher, the .ps1 body escapes ' by doubling it. The read-back comparison is stable on Windows because both the write and the read are in text mode.

Two points:

1. The two Copilot hook forms use different variables. command uses ${PLUGIN_ROOT}, and the new windows form uses $env:CLAUDE_PLUGIN_ROOT. hosts.detect (hosts.py:1243) already treats COPILOT_PLUGIN_ROOT as the variable Copilot sets for its hook processes. $env:COPILOT_PLUGIN_ROOT would avoid depending on Copilot also exporting the Claude-compatible name. If Copilot does export all three, a line saying so in the README would help the next reader.
2. #194 (open) adds a minimum-version check to the shell launchers. It skips a python3 that is older than the bootstrap needs. te.ps1 has no such check, so if #194 lands, the two launchers will choose interpreters differently. te_bootstrap.py still refuses an old Python by itself (MIN_VERSION), so the result is a refusal, not a crash. Whichever PR lands second should probably copy the check.

I didn't run the PowerShell tests.

Reviewed with help from Claude Code.

[Ken Kuang (sykuang)]

Thanks Muhammad Abdullah Butt (@1AbdullahButt). Addressed the root-variable point in 8466f75: all six Windows hooks now use $env:COPILOT_PLUGIN_ROOT. The native hook/slash-command test supplies only that variable, with neither CLAUDE_PLUGIN_ROOT nor PLUGIN_ROOT set. It failed before the change and passes afterward in Windows PowerShell 5.1 and PowerShell 7.

For #194, I checked its current scope: it is still open and explicitly changes the POSIX branches only, leaving Windows untouched. I am keeping Windows version-aware interpreter selection out of this PR rather than pulling that separate change into it. The existing bootstrap minimum-version check still refuses an unsupported interpreter safely; Windows candidate-skipping can be handled in a separate follow-up.