Feature: typisiertes Eingabefeld mit Datei-Write (inkl. secret-Modus) — QoL

[iret77]

Was & warum (QoL, nicht Security-Garantie)

Ein neues form-Feld bzw. eine Feld-Capability: ein typisiertes Eingabefeld, dessen Wert beim Submit (affirmativer Button, nicht Cancel) in eine vom Agent vorgegebene Datei geschrieben wird. secret ist einer der Eingabetypen.

Ziel ist Bequemlichkeit: dem Agent einen sauberen Weg geben, User-Input (besonders Secrets) an seinen Bestimmungsort zu bringen — statt fragiler, geratener Shell-Scripte (siehe Praxisbeispiel unten) oder Arbeitsverweigerung, weil ein Secret nicht in die Session darf. Kein garantierter Schutz vor Agent-Zugriff (wer das braucht, trägt das Secret selbst ein), sondern QoL mit ehrlich dokumentierten Grenzen.

Zwei orthogonale Achsen

Achse	Werte
A: Eingabetyp	string (maxlen, optional pattern), int (min/max), float (min/max), secret (maskiert), …
B: Disposition	an Agent zurück / in Datei schreiben / beides

Constraint: secret ⇒ nur schreiben, Wert wird nie an den Agent zurückgegeben. Für non-secret ist der File-Write reiner Komfort (der Agent hat den Wert ohnehin). → target ist eine optionale Eigenschaft pro Feld, orthogonal zum Typ.

Schreib-Modi (explizit, NICHT aus Datei-Existenz abgeleitet)

Modus aus „Datei existiert?" abzuleiten ist ein Footgun: bei Pfad-Tippfehler/Race kippt sonst still das Verhalten. Daher deklariert der Agent mode explizit; Existenz ist nur geprüfte Vorbedingung:

mode	Vorbedingung	Verhalten	Fehlerfall
create	Datei fehlt (oder overwrite:true)	Datei = roher Eingabewert	existiert ohne overwrite → Fehler
substitute	Datei da, Platzhalter genau 1×	ersetzt den Agent-vorgegebenen Platzhalter durch den Wert; format-agnostisch (YAML/TOML/JSON/INI/…), da reine String-Substitution	0 Treffer → Fehler; >1 → Fehler (oder explizit „all")

Zielort — IMMER der Host, auf dem der Agent läuft

Kein beliebiger Host. Das einzige zulässige Schreibziel ist die Maschine, auf der die Agent-Session läuft:

• Lokale Session → lokaler Dateipfad auf dem Mac (aiui schreibt direkt).
• Remote-Session (SSH) → genau der registrierte Remote, auf dem der Agent läuft (aiui schreibt via vorhandenem SSH-Pfad dorthin zurück; der Wert reist Keyboard → lokales aiui → scp → Remote-Datei, nie durch den Agent-Kontext).

Damit ist Exfiltration auf einen fremden Host strukturell ausgeschlossen — der Agent kann target nicht auf attacker@evil:/exfil zeigen.

Pflicht: User-Freigabe pro Dateioperation

Jede Schreiboperation wird dem User im Dialog zur Freigabe vorgelegt — der affirmative Button ist die Freigabe. Angezeigt wird das aufgelöste Ziel + Modus + Preview:

Schreibe secret nach byte5ai-host:~/.config/foo/key (mode: create, 0600) — [Speichern] [Abbrechen]

Begründung (der eigentliche Sicherheits-Gedanke): aiui ist ein privilegierter Mittelsmann. aiui schreibt mit der SSH-/Datei-Identität des Users; ein sandboxed Agent könnte über aiui Pfade erreichen, die sein eigener direkter Zugriff oder sein Approval-Gate blockiert — klassischer Confused-Deputy. Die zwingende User-Freigabe pro Op schließt diese Lücke: der User ist der Autorisierungs-Backstop und sieht zudem einen falschen Pfad, bevor er bestätigt.

Mechanik

• Wert bei Submit in-memory unter opakem Handle, kein Plaintext-tmp-File.
• aiui schreibt atomar (tmp + rename lokal; analog remote).
• Tool-Result: {written:true, target, bytes} — bei secret ohne Wert; bei non-secret optional Wert + Status.
• Fehler (Permission, Host weg, Platzhalter nicht gefunden, create auf existierende Datei ohne overwrite) → {written:false, error} an den Agent und sichtbar im Dialog. Kein stiller Erfolg.
• In-memory-Eintrag verfällt direkt nach dem Write (oder per TTL) → kein Cleanup-Problem.

Umsetzung: form erweitern, kein neues Widget

Forms haben bereits Button(s), Validierung, Layout, Submit/Cancel. „Referenzierter Button" = affirmativer Submit (Cancel → kein Write). Neu: optionale Feld-Eigenschaft target + Eingabetyp secret. Spart eine parallele Code-Fläche.

{
  "kind": "secret",
  "name": "github_pat",
  "label": "GitHub PAT für byte5ai",
  "target": { "mode": "create", "path": "~/.github_tokens/byte5ai", "perm": "0600", "overwrite": true }
}

Praxisbeispiel (Motivation)

Ein Agent präsentierte dieses Snippet, um einen PAT „am Chat vorbei" zu speichern:

touch ~/.github_tokens && chmod 600 ~/.github_tokens
read -s -p "GitHub PAT für byte5ai: " PAT && echo
( grep -v '^byte5ai=' ~/.github_tokens 2>/dev/null; printf 'byte5ai=%s\n' "$PAT" ) > ~/.github_tokens.tmp
mv ~/.github_tokens.tmp ~/.github_tokens
chmod 600 ~/.github_tokens
unset PAT

Auf dem Host ist ~/.github_tokens aber ein Verzeichnis mit je einer Datei pro Token, keine flache key=value-Datei. Das Snippet hätte: chmod 600 aufs Verzeichnis (→ x-Bit weg → alle Token unlesbar), eine falsch formatierte stray-Datei im Verzeichnis angelegt und den PAT nie am richtigen Ort gespeichert. Der Agent hielt das Secret per read -s/unset bereits aus dem Kontext — das Problem ist nicht Geheimhaltung, sondern dass der Agent die Storage-Konvention raten muss und danebenliegt. Das secret-Feld ersetzt das durch einen nativen Dialog + korrekten, atomaren Write, dessen Ziel der User vorher sieht.

Phasing

• v1: lokal create + substitute; Remote create (scp auf den Agent-Host).
• v1.1: Remote substitute (read-modify-write über ssh) — der teurere, sensiblere Teil.

Offene Fragen

• Session→Remote-Mapping: Bei Remote-Sessions kommt die /render-Anfrage über den Reverse-Tunnel von 127.0.0.1 — wie mappt aiui sie auf den richtigen registrierten Remote? Vermutlich muss das mcp-stdio-Child sich selbst identifizieren. Implementierungs-Detailfrage.
• Host-Validierung: Remote-Ziel zwingend durch is_valid_host_alias + -- end-of-options (sonst kommt die SSH option injection via unvalidated host_alias from Settings UI #52-Option-Injection-Fläche zurück), auch bei Beschränkung auf registrierte Remotes.
• Mehrere Felder mit target: mehrere Writes; bei selber Datei mehrere Platzhalter in einem Pass; Per-Target-Ergebnis + Reihenfolge/Atomarität über mehrere Dateien.
• Validierung von int/float/string clientseitig vor Button-Enable.

[iret77]

Implementiert in PR #138 (commit 5cca712), Release v0.8.0.

v1 geliefert (entspricht dem im Issue definierten v1-Scope):

• Neuer Field-Typ secret + optionale, typ-orthogonale Feld-Eigenschaft target auf jedem Input-Feld.
• Disposition-Constraint umgesetzt: secret ⇒ write-only. Der Wert läuft WebView → Rust-Command write_dialog_targets (lokales IPC) → Datei und wird nie ins dialog_submit-Result gelegt, das an Bridge/Agent geht (auch im Fehlerpfad gestrippt). Non-secret mit target → geschrieben und zurückgegeben.
• Modi explizit, nicht aus Existenz abgeleitet: create (atomar tmp+rename, verweigert Clobber ohne overwrite, setzt perm) und substitute (ersetzt Platzhalter genau 1×; 0/>1 → Fehler, kein Teil-Write).
• Zielort = immer der Agent-Host: lokal (Mac-Pfad) oder Remote-create via scp mit der SSH-Identität des Users. Host-Alias über is_valid_host_alias + -- validiert (SSH option injection via unvalidated host_alias from Settings UI #52-Guard), Pfad metazeichen-frei, Wert nie auf einer Command-Line. session_origin → registrierter Remote; bei Mehrdeutigkeit wird verweigert (keine Exfiltration auf Fremd-Host).
• User-Freigabe pro Op: der affirmative Submit ist die Freigabe; das Feld zeigt vorher das aufgelöste Ziel + Modus + Perm inline an.
• Tool-Doku (Rust + Python Bridge) + skill.md dokumentieren secret/target inkl. ehrlicher Grenzen (QoL + Confused-Deputy-Guard, keine Hard-Garantie).
• Tests: filewrite/remotewrite (atomar, Clobber-Schutz, substitute-once, Origin-Mapping, Alias/Pfad-Reject), 133 Rust-Tests grün.

Bewusst auf v1.1 verschoben (wie im Issue-Phasing): Remote-substitute (read-modify-write über ssh) — gibt aktuell einen klaren „not supported yet"-Fehler statt eines Halb-Writes. Falls gewünscht, eigenes Follow-up-Issue.

[iret77]

Architektur-Korrektur (v0.8.1). Die erste Umsetzung (v0.8.0, nie released) ließ den Mac den Wert per scp zum Remote schieben und verschob Remote-substitute auf v1.1 (Sorge um atomares Remote-Replace). Das war unnötig kompliziert — danke für den Hinweis.

Korrektes Modell: Auf dem Agent-Host läuft ohnehin ein aiui-Modul — lokal die native App, remote die Python-Bridge. Also macht jede Seite einen lokalen File-Write auf ihrem eigenen FS. substitute ist damit überall ein lokaler Read-Modify-Write (atomar via tmp+rename) — kein scp, kein atomares Remote-Replace, kein TOCTOU über die Leitung. Der eingegebene Wert erreicht die schreibende Seite über den bestehenden :7777-Kanal — die Bridge, nie den Agenten/LLM; die Bridge schreibt lokal und strippt das Secret aus dem Result.

Damit:

• Remote substitute funktioniert (war der eigentliche Zweck des Features) — identisch zu lokal.
• Confused-Deputy-Guard ist jetzt strukturell: es gibt keinen Host-Parameter mehr, ein Write kann nur auf dem eigenen Agent-Host landen.
• remotewrite.rs/scp entfernt; Bridge-seitige lokale Write-Logik in filewrite.rs (Rust, App-lokal) + server.py (_apply_target_writes, Bridge-lokal).

Commit 68070e8, Release v0.8.1. Issue bleibt geschlossen.