docs: correct permission finding — auto+haiku denies writes (not a CLI regression), §2 happy-path PASS

This commit is contained in:
mika kuns
2026-07-24 08:08:15 +02:00
parent 79ce7afe46
commit 3211bfc0f9
2 changed files with 2 additions and 2 deletions
+1 -1
View File
@@ -36,7 +36,7 @@ Kein Code-Aufwand, nur Durchspielen mit explizit notiertem Pass-Kriterium. Der G
## Offene Code-Punkte
- **[OFFEN, 2026-07-24] `--permission-mode auto` denied headless Task-Writes (CLI-Regression):** Mit claude CLI **2.1.207** werden in headless `-p`-Runs unter `--permission-mode auto` alle Writes/Edits `denied` (empirisch verifiziert: `auto``permission_denials:[Write]`, keine Datei; `bypassPermissions` → Write ok). `ClaudeArgsBuilder` nutzt `auto` als Default UND mappt explizites `bypassPermissions``auto` (seit `b2eb5fc`, 2026-04-25). Folge: autonome Tasks können im aktuellen Setup keine Dateien ändern (leerer Worktree → WaitingForReview ohne Änderung). `auto` **lief früher** (Gap-Tasks 2026-07-23 unter CLI 2.1.191 haben geschrieben+committet) — es ist eine CLI-seitige Verhaltensänderung von `auto`. Bewusst noch NICHT gefixt (Mika: erst beobachten/abwarten, ob `auto` wieder greift bzw. via settings-allowlist gedacht ist). Fix-Option falls nötig: Default → `bypassPermissions` + auto-Remap raus in `ClaudeArgsBuilder`/`PermissionModeRegistry`. **Blockiert §2 Happy-Path im Verifikations-Handoff.**
- **[OFFEN, 2026-07-24] `--permission-mode auto` + Modell `haiku` → Writes werden denied (haiku-Footgun, KEINE CLI-Regression):** Kontrolliert verifiziert (CLI 2.1.207, gleicher Worker/Tag): unter dem Default-Mode `auto` bekommt **sonnet** Writes auto-approved (`permission_denials:[]`, Datei entsteht), **haiku** wird `denied` (`permission_denials:[Write]`, keine Datei) — haiku steigt beim auto-Permission-Flow aus, statt zu schreiben. Folge: eine Task, die (per MCP `model:"haiku"` oder Task-Override) auf haiku läuft, macht unter `auto` **still nichts** und landet ohne Änderung in `WaitingForReview`. Normalbetrieb (Default = sonnet) ist nicht betroffen; die Gap-Tasks 2026-07-23 liefen sonnet und haben geschrieben+committet. Ursprünglich fälschlich als CLI-`auto`-Regression gemeldet — das war ein Testartefakt (haiku-Tasks zum „Sparen"). Optionen falls es nervt: haiku aus der Auswahl nehmen, ODER Runner auf `acceptEdits`/`bypassPermissions` (modell-unabhängig) statt `auto`.
- **Status-Bar Live-Update:** Prüfen, ob `RunNow`-Enable/Disable pro Task-Row bei Connection-Change sauber re-evaluiert. Connection-Status lebt in `IslandsShellViewModel` / `WorkerConnectionModalViewModel` (es gibt keinen `StatusBarViewModel` mehr). Erst messen, dann ggf. fixen. Klein.
## Nachklapp Refactoring-/Bug-Runde (2026-06-09/10)