Copilot-Hooks unter Windows: ./tools/trace-hook öffnet den Dialog „App auswählen“, statt still zu laufen
#164
Reference in new issue
Block a user
./tools/trace-hook öffnet den Dialog „App auswählen“, statt still zu laufen
#164
Befund aus der Handprüfung von #151 auf dem Windows-Zielsystem (2026-10-01). Gehört zu #140 und betrifft D36 (Hooks über die venv-Python).
Erledigt (geschlossen 2026-10-02). Gebaut in
9d06050(8.0.0-beta.18), CI 482/483 grün. Die Handprüfung des Betreibers auf dem Zielsystem (Checkout auf beta.22) bestätigt den Fix in Copilot CLI und in Copilot in VS Code.Befund
Auf dem Zielsystem lief Copilot (pwsh 7.6.6) im Checkout
C:\cmauf Stand 8.0.0-beta.17. Bei Hook-Ereignissen öffnete Windows den Dialog „App auswählen“, umtrace-hookzu öffnen. Der Betreiber hat ihn jedes Mal weggeklickt; danach lief der Befehl normal.Der Dialog zeigte: Eine PowerShell hat
./tools/trace-hook …ausgeführt. Für eine Datei ohne Endung kennt Windows keine App, also fragt es.Ursache (geklärt gegen Doku und Quelltext der Clients, bestätigt durch die Handprüfung)
Die ursprüngliche Vermutung war: Unter Windows wird der
bash-Eintrag aus.github/hooks/wiki-trace.jsonausgeführt. Das stimmt laut Doku für keinen der beiden Clients.powershellVorrang,commandist der Fallback. Copilot CLI liest Hooks aber auch aus.claude/settings.json(„Cross-tool .claude/settings.json … are also read“). Dort steht genau ein Eintrag (UserPromptSubmit), und der hat nurcommand: ./tools/trace-hook --source claude-code … 2>/dev/null || true. Diesencommandführte Copilot CLI unter Windows in pwsh aus, und er landete bei der Dateizuordnung – einmal pro Prompt, also vor den Befehlen des Agenten. Mittrace-hook.ps1ist der Dialog weg.hookSchema.ts,normalizeHookCommand):powershellwird aufwindowsabgebildet,bashauflinux/osx. Unter Windows läuft also derpowershell-Eintrag..claude/settings.jsonliest VS Code nur mitchat.useClaudeHooks. Nebenbefund: VS Code führt Hooks unter Windows mitpowershell.exe5.1 aus (hookExecutor.ts,getShellCommand, solangeComSpeccmd.exe ist), nicht mit pwsh 7. Unserepowershell-Einträge laufen auch dort. Der Claude-Eintrag scheitert unter 5.1 an||(Syntaxfehler), ohne Dialog und ohne Blockade.tools/xunter Windows zuerst aufx.ps1auf, vor.cmdund vor der Datei ohne Endung.Umsetzung
tools/trace-hook.ps1ist der PowerShell-Zwilling vontools/trace-hook, nach dem Muster vonwikitool/wikitool.ps1(D15). Jede PowerShell unter Windows, die./tools/trace-hook …ausführt, landet damit in der.ps1statt bei der Dateizuordnung. Das gilt egal, aus welcher Datei der Befehl stammt und welcher Client ihn startet. Die Befehlsstrings in den drei Hook-Dateien sind unverändert..ps1rufttrace_ingest.pymit der venv-Python auf (Scripts\python.exe, sonstbin/python). Sie unterdrückt stderr und endet immer mit 0 (trap { exit 0 },exit 0). Ohne venv bleibt sie still.#Requires -Version 7, nur 5.1-taugliche Syntax: Ein Hook darf nie scheitern, auch wenn ihn eine 5.1 startet.doctorerfasst die Datei ohne Änderung (tools/**/*.ps1), ebenso PSScriptAnalyzer im CI (tools/*.ps1, 0 Befunde).dist exportliefert sie aus.tools/README.md, Kommentar intools/trace-hook, CHANGES.md.Ausgelagert:
prompt.submittedmit--source claude-code(Hinweis an #82).tools/wikitool doctordie App-Auswahl für den sh-Starter, nicht für den Hook. Der Betreiber vermutet eine lokale Konfiguration des Klons; der Test folgt später.Handprüfung (Betreiber, 2026-10-02, Checkout auf beta.22)
prompt.submittedsowietool.pre/tool.post.pwsh -NoProfile -ExecutionPolicy Bypass -File tools/preflight.ps1.prompt.submittedim Trace, keintool.pre/tool.post– erwartet, weil.claude/settings.jsonnurUserPromptSubmitverdrahtet (#82). Kein Befund gegen dieses Issue.Akzeptanzkriterien
./tools/trace-hook …hat mittools/trace-hook.ps1eine Datei, die PowerShell selbst ausführt.test_every_extensionless_hook_target_has_a_powershell_twinsichert das ab.trace-hook.ps1reicht stdin und die Argumente antrace_ingest.pyunter der venv-Python durch (beide Layouts). Ohne venv bleibt es still und endet mit 0. Es endet auch mit 0, wenn die Python scheitert. Abgedeckt durch drei pwsh-Tests intest_preflight_pwsh.py, grün lokal und im CI-Jobpwsh.reports/(Handprüfung 2026-10-02:prompt.submitted,tool.pre/tool.postin Copilot CLI und VS Code).test_no_hook_relies_on_a_shebang_or_a_bare_pythonist grün (volle Suite: 1923 passed).tools/README.mdnennen die.ps1und den Grund.Version
--patch, drop-in (8.0.0-beta.18). Das Schließen hat keine Datei berührt.Changelog: Die Ursache ist korrigiert. Nicht der
bash-Zweig läuft unter Windows, sondern Copilot CLI führt dencommandaus.claude/settings.jsonin pwsh aus (laut Doku; VS Code laut Quelltext nicht betroffen). Die Umsetzung (tools/trace-hook.ps1) ist in9d06050/ 8.0.0-beta.18 gebaut, CI 482/483 grün. Die Kriterien 2, 3, 5 und 6 sind abgehakt. Offen ist die Handprüfung (Kriterien 1 und 4), Ablauf im Body. Der Nebenbefund ist ausgelagert nach #165.Changelog (2026-10-02): Die Handprüfung (Kriterien 1 und 4) hat der Betreiber zurückgestellt; er macht sie später selbst. Neu geprüft: Im Code ist nichts mehr offen. Neu gelabelt:
prio/blocking→prio/waiting, Auslöser ist die Handprüfung. Der Fix ist veröffentlicht, also blockiert das Issue keine laufende Arbeit mehr. Es bleibt Freigabebedingung für 8.0.0. Der Body nennt den Schritt nach der Handprüfung und den Weg zurück aufprio/blocking, falls doch ein Dialog kommt.Changelog (2026-10-02): Die Handprüfung des Betreibers auf beta.22 ist eingetragen. Unter Copilot CLI erscheint kein Hook-Dialog mehr, und der Trace ist vollständig; damit sind Kriterium 1 und 4 für Copilot CLI bestätigt. Unter Claude Code fehlen
tool.pre/tool.post; das ist erwartet und gehört zu #82. Copilot in VS Code ist noch offen. Der Nebenbefund zutools/wikitoolunter Copilot CLI ist nach #167 ausgelagert.Changelog (2026-10-02): Copilot in VS Code ist bestätigt (Betreiber): Traces wie erwartet, kein Dialog gemeldet. Damit sind Kriterium 1 und 4 für beide Clients erfüllt. Der Body steht im Endzustand. Geschlossen.