Befund aus der Handprüfung von #164 auf dem Windows-Zielsystem (Betreiber, 2026-10-02). Gehört zu #140 (D15). prio/ und size/ sind vorläufig, solange status/unconfirmed steht.
Stand (2026-10-02): wartet auf den Test durch den Betreiber (prio/waiting). Der Betreiber schätzt die Ursache als lokale Konfiguration von Copilot CLI ein. Bis zum Test ist das Issue keine Freigabebedingung für 8.0.0.
Beobachtet
Im Checkout auf 8.0.0-beta.22 rief der Agent in Copilot CLI (pwsh 7) tools/wikitool doctor auf. Windows öffnete den Dialog „App auswählen“ für die Datei wikitool ohne Endung, also für den sh-Starter.
Der Agent versuchte es danach über wikitool.ps1 und lief in die Execution Policy. Laut Betreiber ist der Klon vermutlich nicht korrekt aufgesetzt.
In Claude Code (Git Bash) lief tools/wikitool doctor im selben Checkout.
In Copilot in VS Code startete der Agent im selben Checkout den Preflight über pwsh -NoProfile -ExecutionPolicy Bypass -File tools/preflight.ps1, also mit prozessweitem Bypass.
Die Hooks liefen im selben Checkout ohne Dialog über tools/trace-hook.ps1 (#164).
Warum das auffällt
Nach T1 (#140) löst pwsh 7 unter Windows tools/x zuerst auf x.ps1 auf, vor .cmd und vor der Datei ohne Endung. In der Handprüfung von #151 (2026-10-01) lief tools/wikitool auf diesem Rechner auch genau so (#140, Befund 3 „auf dem Zielsystem bestätigt“). Wenn jetzt die Datei ohne Endung gestartet wird, hat pwsh die .ps1 nicht genommen.
Hypothesen (ungeprüft)
Die Execution Policy sperrt .ps1 in diesem Klon, etwa durch eine Markierung „aus dem Internet“ (MotW) oder durch eine Policy Restricted/AllSigned für den Prozess, den Copilot CLI startet. Ungeklärt ist, ob pwsh dann auf die Datei ohne Endung ausweicht, statt mit dem Policy-Fehler abzubrechen. Das lässt sich nur unter Windows prüfen. Der Bypass-Aufruf in VS Code passt zu dieser Hypothese.
Copilot CLI ruft den Befehl anders auf als eine interaktive pwsh, etwa mit einem anderen Pfad oder über einen Start, der die Dateizuordnung nutzt. Dann läge die Ursache im Harness, nicht im Klon.
Der Klon ist nicht vollständig auf dem Stand, etwa ohne tools/wikitool.ps1.
Zur Bestätigung (Betreiber, im betroffenen Checkout, in pwsh 7)
Der Preflight prüft im Baum die Policy und die Markierungen. Bei einem Problem hält er mit Exit 42 und einer Anleitung an, und doctor zeigt danach execution-policy und script-marks. Danach tools/wikitool doctor in Copilot CLI noch einmal.
Ausgang
Der Preflight findet eine Policy- oder MotW-Ursache, und nach der Behebung läuft tools/wikitool in Copilot CLI: Das ist ein Umgebungsfall. Offen bleibt dann nur, ob pwsh bei einer gesperrten .ps1 still auf die Datei ohne Endung ausweicht. Falls ja, sollte die Meldung des Preflights oder INSTALL.md diesen Dialog als Symptom nennen. Sonst Schließen mit Begründung.
Der Klon ist sauber, und der Dialog bleibt: Das ist ein echter Defekt am Launcher-Muster D15 unter Copilot CLI (prio/blocking), weil der Agent dann wikitool nicht starten kann. Ist 8.0.0 bis dahin freigegeben, wird es ein Patch darauf.
Befund aus der Handprüfung von #164 auf dem Windows-Zielsystem (Betreiber, 2026-10-02). Gehört zu #140 (D15). `prio/` und `size/` sind vorläufig, solange `status/unconfirmed` steht.
**Stand (2026-10-02):** wartet auf den Test durch den Betreiber (`prio/waiting`). Der Betreiber schätzt die Ursache als lokale Konfiguration von Copilot CLI ein. Bis zum Test ist das Issue keine Freigabebedingung für 8.0.0.
## Beobachtet
- Im Checkout auf 8.0.0-beta.22 rief der Agent in **Copilot CLI** (pwsh 7) `tools/wikitool doctor` auf. Windows öffnete den Dialog „App auswählen“ für die Datei `wikitool` ohne Endung, also für den sh-Starter.
- Der Agent versuchte es danach über `wikitool.ps1` und lief in die Execution Policy. Laut Betreiber ist der Klon vermutlich nicht korrekt aufgesetzt.
- In **Claude Code** (Git Bash) lief `tools/wikitool doctor` im selben Checkout.
- In **Copilot in VS Code** startete der Agent im selben Checkout den Preflight über `pwsh -NoProfile -ExecutionPolicy Bypass -File tools/preflight.ps1`, also mit prozessweitem Bypass.
- Die Hooks liefen im selben Checkout ohne Dialog über `tools/trace-hook.ps1` (#164).
## Warum das auffällt
Nach T1 (#140) löst pwsh 7 unter Windows `tools/x` zuerst auf `x.ps1` auf, vor `.cmd` und vor der Datei ohne Endung. In der Handprüfung von #151 (2026-10-01) lief `tools/wikitool` auf diesem Rechner auch genau so (#140, Befund 3 „auf dem Zielsystem bestätigt“). Wenn jetzt die Datei ohne Endung gestartet wird, hat pwsh die `.ps1` nicht genommen.
## Hypothesen (ungeprüft)
1. **Die Execution Policy sperrt `.ps1` in diesem Klon**, etwa durch eine Markierung „aus dem Internet“ (MotW) oder durch eine Policy `Restricted`/`AllSigned` für den Prozess, den Copilot CLI startet. Ungeklärt ist, ob pwsh dann auf die Datei ohne Endung ausweicht, statt mit dem Policy-Fehler abzubrechen. Das lässt sich nur unter Windows prüfen. Der Bypass-Aufruf in VS Code passt zu dieser Hypothese.
2. **Copilot CLI ruft den Befehl anders auf als eine interaktive pwsh**, etwa mit einem anderen Pfad oder über einen Start, der die Dateizuordnung nutzt. Dann läge die Ursache im Harness, nicht im Klon.
3. **Der Klon ist nicht vollständig auf dem Stand**, etwa ohne `tools/wikitool.ps1`.
## Zur Bestätigung (Betreiber, im betroffenen Checkout, in pwsh 7)
```powershell
Get-ExecutionPolicy -List
Get-Item tools\wikitool.ps1 -Stream Zone.Identifier
pwsh -NoProfile -ExecutionPolicy Bypass -File tools/preflight.ps1
```
Der Preflight prüft im Baum die Policy und die Markierungen. Bei einem Problem hält er mit Exit 42 und einer Anleitung an, und `doctor` zeigt danach `execution-policy` und `script-marks`. Danach `tools/wikitool doctor` in Copilot CLI noch einmal.
## Ausgang
- **Der Preflight findet eine Policy- oder MotW-Ursache, und nach der Behebung läuft `tools/wikitool` in Copilot CLI:** Das ist ein Umgebungsfall. Offen bleibt dann nur, ob pwsh bei einer gesperrten `.ps1` still auf die Datei ohne Endung ausweicht. Falls ja, sollte die Meldung des Preflights oder `INSTALL.md` diesen Dialog als Symptom nennen. Sonst Schließen mit Begründung.
- **Der Klon ist sauber, und der Dialog bleibt:** Das ist ein echter Defekt am Launcher-Muster D15 unter Copilot CLI (`prio/blocking`), weil der Agent dann `wikitool` nicht starten kann. Ist 8.0.0 bis dahin freigegeben, wird es ein Patch darauf.
Changelog (2026-10-02): Der Betreiber schätzt die Ursache als lokale Konfiguration von Copilot CLI ein und testet später. Neu gelabelt: prio/planned → prio/waiting; der Auslöser ist dieser Test. Bis dahin ist das Issue keine Freigabebedingung für 8.0.0.
Neue Beobachtung, passend zu Hypothese 1: Auch der Agent in Copilot in VS Code startete im selben Checkout den Preflight über pwsh -NoProfile -ExecutionPolicy Bypass -File tools/preflight.ps1, also mit prozessweitem Bypass.
**Changelog (2026-10-02):** Der Betreiber schätzt die Ursache als lokale Konfiguration von Copilot CLI ein und testet später. Neu gelabelt: `prio/planned` → `prio/waiting`; der Auslöser ist dieser Test. Bis dahin ist das Issue keine Freigabebedingung für 8.0.0.
Neue Beobachtung, passend zu Hypothese 1: Auch der Agent in Copilot in VS Code startete im selben Checkout den Preflight über `pwsh -NoProfile -ExecutionPolicy Bypass -File tools/preflight.ps1`, also mit prozessweitem Bypass.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Befund aus der Handprüfung von #164 auf dem Windows-Zielsystem (Betreiber, 2026-10-02). Gehört zu #140 (D15).
prio/undsize/sind vorläufig, solangestatus/unconfirmedsteht.Stand (2026-10-02): wartet auf den Test durch den Betreiber (
prio/waiting). Der Betreiber schätzt die Ursache als lokale Konfiguration von Copilot CLI ein. Bis zum Test ist das Issue keine Freigabebedingung für 8.0.0.Beobachtet
tools/wikitool doctorauf. Windows öffnete den Dialog „App auswählen“ für die Dateiwikitoolohne Endung, also für den sh-Starter.wikitool.ps1und lief in die Execution Policy. Laut Betreiber ist der Klon vermutlich nicht korrekt aufgesetzt.tools/wikitool doctorim selben Checkout.pwsh -NoProfile -ExecutionPolicy Bypass -File tools/preflight.ps1, also mit prozessweitem Bypass.tools/trace-hook.ps1(#164).Warum das auffällt
Nach T1 (#140) löst pwsh 7 unter Windows
tools/xzuerst aufx.ps1auf, vor.cmdund vor der Datei ohne Endung. In der Handprüfung von #151 (2026-10-01) lieftools/wikitoolauf diesem Rechner auch genau so (#140, Befund 3 „auf dem Zielsystem bestätigt“). Wenn jetzt die Datei ohne Endung gestartet wird, hat pwsh die.ps1nicht genommen.Hypothesen (ungeprüft)
.ps1in diesem Klon, etwa durch eine Markierung „aus dem Internet“ (MotW) oder durch eine PolicyRestricted/AllSignedfür den Prozess, den Copilot CLI startet. Ungeklärt ist, ob pwsh dann auf die Datei ohne Endung ausweicht, statt mit dem Policy-Fehler abzubrechen. Das lässt sich nur unter Windows prüfen. Der Bypass-Aufruf in VS Code passt zu dieser Hypothese.tools/wikitool.ps1.Zur Bestätigung (Betreiber, im betroffenen Checkout, in pwsh 7)
Der Preflight prüft im Baum die Policy und die Markierungen. Bei einem Problem hält er mit Exit 42 und einer Anleitung an, und
doctorzeigt danachexecution-policyundscript-marks. Danachtools/wikitool doctorin Copilot CLI noch einmal.Ausgang
tools/wikitoolin Copilot CLI: Das ist ein Umgebungsfall. Offen bleibt dann nur, ob pwsh bei einer gesperrten.ps1still auf die Datei ohne Endung ausweicht. Falls ja, sollte die Meldung des Preflights oderINSTALL.mddiesen Dialog als Symptom nennen. Sonst Schließen mit Begründung.prio/blocking), weil der Agent dannwikitoolnicht starten kann. Ist 8.0.0 bis dahin freigegeben, wird es ein Patch darauf.Changelog (2026-10-02): Der Betreiber schätzt die Ursache als lokale Konfiguration von Copilot CLI ein und testet später. Neu gelabelt:
prio/planned→prio/waiting; der Auslöser ist dieser Test. Bis dahin ist das Issue keine Freigabebedingung für 8.0.0.Neue Beobachtung, passend zu Hypothese 1: Auch der Agent in Copilot in VS Code startete im selben Checkout den Preflight über
pwsh -NoProfile -ExecutionPolicy Bypass -File tools/preflight.ps1, also mit prozessweitem Bypass.