journal day

Freitag, 27. März 2026

Tagesansicht des öffentlichen Journals: konkrete Changelog-Outputs, Incidents und kuratierte Notes, ohne dass der Index alles auf einmal rendert.

Aktivität an diesem Tag: Spitze

Freitag, 27. März 2026

codexopenclaw

PortTalk-Gruppenroute fuer @foliopingbot erweitert

changed

**`.openclaw/openclaw.json`**
`channels.telegram.groups["-5282701263"].allowFrom` um `@foliopingbot` erweitert.
Die PortTalk-Gruppe bleibt weiter explizit auf bekannte Sender begrenzt, ist jetzt aber nicht mehr nur fuer Dominiks Nutzer-ID offen.

verified

Hot-Reload griff auf `channels.telegram.groups.-5282701263.allowFrom`.
anschliessender Gateway-Restart erfolgreich; `openclaw-gateway.service` wieder `active`.
geladene Gruppen-Route zeigt jetzt:
`8424800642`
`@foliopingbot`

codexopenclaw

Buch-Chronologie fuer OpenClaw als Arbeitsoutline abgelegt

changed

**`.openclaw/workspace/plans/openclaw-book-chronology-outline.md`** neu angelegt.
Zwei moegliche Buchfassungen festgehalten:
dramatischere OpenClaw-Chronik
nuechterne Builder-/Memoir-Version
gemeinsamen roten Faden, wiederkehrende Motive und die spaetere sinnvolle Weiterarbeit dokumentiert.

verified

Outline verweist explizit auf Changelog, Agent-Changelog und Incident Log als Quellenbasis.
Beide Fassungen sind nebeneinander abgelegt, damit spaeter nicht erneut zwischen Tonalitaeten verloren gegangen wird.

codexopenclaw

Agent-Bridge-Inkubator-Roadmap abgelegt und AB-Todos auf V1-Reihenfolge gezogen

changed

**`.openclaw/workspace/plans/agent-bridge-incubator-roadmap.md`** neu angelegt.
Zielbild fuer den Inkubator als lokal betriebene, menschlich moderierte Diskussionsumgebung definiert.
klares Phasenmodell festgelegt: Round-Prinzip zuerst, dann Lifecycle, systemd-Betrieb, `tyrone`, lokale Web-GUI.
Safety Rails festgehalten: keine Endlos-Loops, keine implizite Ausfuehrung, GUI nur lokal, Telegram nur Adapter.
**`.openclaw/workspace/tasks/todo.md`**
AB-Sektion um V1-Roadmap erweitert.
neue Folgepunkte `AB-8` bis `AB-13` fuer Lifecycle, Moderation, Inkubator-Trennung, systemd, `tyrone` und lokale GUI angelegt.

verified

Plan ist bewusst vom bestehenden Architekturpapier getrennt abgelegt, damit MVP-Basis und Inkubator-Zielbild nicht vermischt werden.
Todo referenziert jetzt explizit den neuen Roadmap-Pfad und die empfohlene Reihenfolge.

codexopenclaw

Tyrone bekommt bei Robin/Bill wieder das echte Deliverable statt Meta-Report

changed

**`.openclaw/workspace/agents/division_runner.py`**
`run_division()` liefert jetzt zusaetzlich `delivery_text` fuer direkte Head-Aufrufe.
Content-Outputs werden fuer Direktantworten auf den eigentlichen Draft reduziert; `SCHEDULE:`-/`POSTFAST`-Metadaten fliegen dabei raus.
**`.openclaw/workspace/agents/dispatch.py`**
`run_division_head()` bevorzugt fuer `robin` und `bill` jetzt `delivery_text` statt nur den Head-Report.

verified

`python3 -m py_compile` fuer `division_runner.py` und `dispatch.py` erfolgreich.
Helper-Smokes bestaetigen:
JSON-Content -> eigentlicher Draft + Alt-Versionen
Raw-PostFast-Output -> Draft ohne Scheduling-/Statuszeilen
Dispatch-Smoke mit gemocktem `run_division()` liefert bei `robin` und `bill` den neuen Rueckkanal.

codexopenclaw

Telegram-Gruppen fuer Tyrone sauber freigeschaltet

changed

**`.openclaw/openclaw.json`**
`channels.telegram.groups` zuerst als Wildcard geoeffnet und danach auf die echte Telegram-Gruppen-ID `-5282701263` verengt.
Gruppenverkehr bleibt auf Dominiks Telegram-ID begrenzt (`8424800642`), ist aber nicht mehr im OpenClaw-Setup selbst als "first-time setup blockiert" konfiguriert.
`requireMention` fuer die Gruppen-Route auf `false` gesetzt, damit Tyrone in genau dieser Gruppe auch ohne explizites `@EPalazzo_bot` auf Dominiks Nachrichten reagieren kann.

verified

`systemctl --user restart openclaw-gateway.service` erfolgreich; Gateway danach wieder `active`.
`openclaw doctor` meldet keine Telegram-Setup-Blockade und keine Channel-Sicherheitswarnung mehr.
`getMe` fuer `@EPalazzo_bot` bestaetigt jetzt:
`can_join_groups=true`
`can_read_all_group_messages=true`
Session-Store zeigt den echten Live-Gruppenpfad:
`agent:main:telegram:group:-5282701263`

note

Der Gruppenpfad ist jetzt technisch live.
Der `openclaw doctor` Hinweis auf Privacy-Mode bleibt nach dem Wechsel aktuell noch als konservative Warnung stehen, obwohl die Live-Telegram-API bereits `can_read_all_group_messages=true` meldet.

codexopenclaw

Queue-first Posting fuer @th3_m0l3 auf drei produktive Slots umgestellt

changed

**`.openclaw/cron/jobs.json`**
alle festen Direkt-Trigger `postfast:thread-*` / `postfast:tweet-*` fuer `@th3_m0l3` pausiert, damit keine parallelen Scheduler mehr an PostFast liefern.
`twitter:auto-post-morning` von `ragebait -> public_news` auf Queue-first umgestellt (`public_news -> market_commentary -> evergreen`).
neuen Slot `twitter:auto-post-us-open-en` fuer `15:45 Europe/Berlin` angelegt; dispatcht nur englische Queue-Items (`language=en`) rund um den US-Market-Open.
`twitter:auto-post-evening` auf `evergreen -> public_news -> ragebait` vereinheitlicht.
`twitter:public-news-refill` auf konservativere Time-Critical-Flags umgestellt (`--time-critical-hours 4 --max-urgent 2 --min-urgent-score 5`).
**`workspace/content/tweets/POSTING_PLAN.md`**
Queue-first Posting-Plan auf 3 Slots aktualisiert und die pauschalen Direkt-PostFast-Slots als pausiert dokumentiert.
**`workspace/WORKFLOW_AUTO.md`**
Tagesablauf fuer Tyrone auf die drei aktiven Queue-Slots plus stricteres Telegram-Draft-Gate umgestellt.
**`workspace/tasks/todo.md`**
Twitter/PostFast-Status auf den neuen Source-of-Truth-Stand gebracht; offener Rest ist jetzt nur noch der 10-20-Tage-Horizont.

verified

`python3`-Check auf `.openclaw/cron/jobs.json`:
`enabled_postfast_jobs = 0`
aktive Queue-Slots: `twitter:auto-post-morning`, `twitter:auto-post-us-open-en`, `twitter:auto-post-evening`
Dry-Runs fuer die drei produktiven Slots erfolgreich:
Morning-Dispatch pickt ein `public_news`-Queue-Item
US-Open-Dispatch meldet `Language filter used: en` und pickt ein englisches Queue-Item
Evening-Dispatch pickt ein `evergreen`-Queue-Item

note

Die Source-of-Truth-Frage ist damit geklaert: Queue -> Dispatch -> PostFast.
Offen bleibt nur noch die eigentliche Vorausplanung in PostFast (10-20 Tage Horizont), nicht mehr der doppelte Scheduler-Pfad.

codexopenclaw

Night-Action Recovery auf systemd vervollstaendigt

changed

**`workspace/agents/cron/nightaction-execute.sh`**
03:30-Recovery-Modus eingebaut: nur offene kritische Tasks werden nachgezogen, bestehendes Tages-Feedback wird gemerged statt ueberschrieben.
finaler Run-Abschluss schreibt jetzt ehrlich `fail`, sobald im Night-Run echte Task-Fehlschlaege verblieben sind.
**`~/.config/systemd/user/nightaction-recovery.service`** neu angelegt.
**`~/.config/systemd/user/nightaction-recovery.timer`** neu angelegt und aktiviert (`03:30 Europe/Berlin`, `Persistent=true`).
**`.openclaw/cron/jobs.json`**
deaktivierte Alt-Eintraege `nightaction:plan` und `nightaction:execute` vollstaendig entfernt, damit user-systemd auch dateiseitig die einzige Night-Action-Triggerquelle bleibt.

verified

`nightaction-recovery.timer` ist aktiv; `systemctl --user list-timers --all` zeigt jetzt Plan (`01:00`), Execute (`02:01`) und Recovery (`03:30`) konsistent aus user-systemd.
Isolierter Recovery-Smoke:
fuehrt nur den offenen kritischen Task erneut aus
zweiter Recovery-Lauf skippt sauber, wenn alle kritischen Lanes bereits gruen sind
Isolierter Fail-Smoke:
Night-Feedback endet jetzt mit `status=fail`
kanonischer `nightaction-status-YYYY-MM-DD.json` endet ebenfalls mit `status=fail`
`jobs.json` ist JSON-valide und enthaelt keine `nightaction:plan`-/`nightaction:execute`-Altjobs mehr.
Gateway-Journal vom 2026-03-27 zeigt keine neuen Night-Action-Scheduler-Ausloesungen aus dem Agent-Cron.

note

Fuer `OPS-8` bleibt jetzt nur noch der naechste echte Live-Lauf als letzter Beweis offen: Plan um `01:00`, Execute um `02:01` und Recovery um `03:30` sollen auf dem neuen systemd-only Setup einmal komplett ohne Doppelstart durchlaufen.

codexopenclaw

Server-Cutover: Altserver entkoppelt, neue Host-Jobs aktiv

changed

**Neuer Host (`ubuntu-16gb-fsn1-1`)**
User-Crontab aus `.openclaw/tli-briefing/crontab-server-cutover-2026-03-27.txt` aktiviert.
Umgezogen auf den neuen Server: `TLI Gmail Hook` (alle 4h), `Event Scout Mainz` (11:00/) und `X Analytics CSV Download + Import` ().
Tailscale-Funnel fuer den Gmail-Push-Weg verifiziert: `/gmail-push-5f4b3181` zeigt auf den neuen Host und `http://[localhost]`.
**Alter Host (`ubuntu-4gb-nbg1-1`)**
Bestehende User-Crontab nach `.openclaw/tli-briefing/crontab-legacy-2026-03-27.txt` gesichert und danach entfernt.
`openclaw-gateway.service`, `nightaction-plan.timer` und `nightaction-execute.timer` per `systemctl --user disable --now` stillgelegt.
Verwaisten Tailscale-Funnel fuer `/gmail-push-5f4b3181` entfernt (`tailscale funnel reset`), damit der Gmail-Push-Pfad nicht mehr doppelt auf alt und neu publiziert wird.
**VS Code / Copilot Chat**
Veraltete Frontmatter-Eintraege in `Ask.agent.md`, `Explore.agent.md` und `Plan.agent.md` bereinigt (nicht mehr vorhandene GitHub-Tools + altes Gemini-Preview-Modell entfernt), damit die Problem-Ansicht auf dem neuen Server nicht mehr mit Cache-Warnungen zugelaufen wird.

verified

Neuer Host:
`openclaw-gateway.service` aktiv
`nightaction-plan.timer` und `nightaction-execute.timer` aktiv
Live-Run `~/.openclaw/tli-briefing/tli-gmail-hook-v2.mjs` erfolgreich: 5 Portfolio-Mails in Supabase geschrieben, markiert und `resultSizeEstimate: 0`
Live-Run `thelonginvestor/scripts/x-analytics-cron.sh` erfolgreich: Summary-CSV importiert (7 Tage), Posts-CSV importiert (395 Posts)
Live-Run `workspace/scripts/event-scout-mainz.py` erfolgreich; Alert-Datei/Log wurden aktualisiert
Alter Host:
`openclaw-gateway.service` inaktiv
`nightaction-plan.timer` und `nightaction-execute.timer` inaktiv
keine User-Crontab mehr
`tailscale funnel status` -> `No serve config`

note

Der OpenClaw-Gateway-Gmail-Watcher auf dem neuen Host startet weiter mit `gog`-Watch-Serve, meldet beim aktiven OAuth-Call aber `invalid_grant`. Der produktive TLI-Intake ist deshalb jetzt bewusst ueber den funktionierenden 4h-Cron-Hook auf dem neuen Server abgesichert; fuer echtes Gmail-Push-Renewal bleibt ein spaeteres `gog login`/Re-Auth offen.

codexopenclaw

Google OAuth: `gog` reauth + Gmail-Watcher wieder gruen

fixed

`gog` OAuth fuer `[E-Mail]` auf dem neuen Server erfolgreich neu autorisiert.
`openclaw-gateway.service` danach neu gestartet, damit der Gmail-Watcher den frischen Token sofort uebernimmt.

verified

`gog auth list` zeigt den Account jetzt mit neuem OAuth-Zeitstempel `2026-03-27`.
`gog drive search 'The Long Investor' --max 1 --json` funktioniert wieder erfolgreich.
`gog gmail search 'is:unread newer_than:1d' --max 1 --json` funktioniert wieder erfolgreich.
Gateway-Logs zeigen keinen `invalid_grant` mehr; stattdessen:
`watch started for [E-Mail]`
`gmail watcher started for [E-Mail]`
`[gog] watch: listening on [localhost]/`

note

`gog people me` liefert aktuell noch `403 accessNotConfigured`, weil die Google People API im Projekt `409420975569` nicht aktiviert ist. Das ist kein OAuth-Problem mehr und blockiert weder Gmail-Watcher noch Drive.

antigravityopenclaw

Server-Migration: Gateway-Fix + Infrastruktur-Validierung

fixed

**openclaw.json:** `compaction` Keys aus `agents.list[0]` (main) und `agents.list[1]` (doug) entfernt — v2026.3.24 akzeptiert diesen Key nicht mehr in Agent-Listen-Eintraegen. Gateway crashte im Endlos-Restart-Loop (197+ Restarts).
**openclaw-gateway.service:** Version-Label von `v2026.3.7` auf `v2026.3.24` korrigiert, `daemon-reload` ausgefuehrt.

verified

Gateway: `{"ok":true,"status":"live"}` auf `localhost:28456/health`
Tailscale: eingeloggt, `--operator=openclaw` gesetzt, 3 Nodes sichtbar (neuer Server + Desktop + alter Server), Funnel on
fail2ban: aktiv (sshd jail)
Swap: 2GB aktiv
Node: v22.22.2
OpenClaw CLI: v2026.3.24
Disk: 150GB, 14% belegt (125GB frei)
RAM: 15GB total, 13GB verfuegbar

note

`compaction` Key in `agents.defaults` (Zeile 199-207) bleibt bestehen — nur die `agents.list`-Eintraege wurden vom Gateway als ungueltig gemeldet.

Incidents

OpenClaw Gateway / Telegram Groups

~10 mincodex

Problem: Tyrone durfte in `PortTalk` nur auf Dominiks Sender-ID reagieren, aber nicht auf den Folioping-/Parqet-Bot in derselben Gruppe

Ursache: Die Gruppen-Route war nach dem ersten Fix bewusst eng auf `8424800642` begrenzt; fuer Bot-zu-Bot-Interaktion fehlte ein zusaetzlicher Allowlist-Eintrag fuer den Folioping-Sender

Fix: `channels.telegram.groups["-5282701263"].allowFrom` um `@foliopingbot` erweitert, Hot-Reload + Gateway-Restart verifiziert; PortTalk bleibt weiterhin auf bekannte Sender beschraenkt statt global offen

Agent System / Tyrone Content-Delivery

~25 mincodex

Problem: Direkte Robin/Bill-Aufrufe lieferten an Tyrone oft nur Head-Reports oder Meta-Text statt des eigentlichen Drafts/Ergebnisses

Ursache: `dispatch.py` nutzte nach `run_division()` stumpf `data["report"]`; der benutzernahe Deliverable-Text aus dem Agent-Result wurde nirgendwo bevorzugt ausgegeben

Fix: In `division_runner.py` einen expliziten `delivery_text`-Rueckkanal eingebaut, Content-JSON/Raw-Outputs fuer Direktantworten formatiert und Metadaten wie `SCHEDULE`/`POSTFAST` entfernt; `dispatch.py` gibt fuer Robin/Bill jetzt bevorzugt `delivery_text` aus

Twitter / Queue-First Scheduler

~35 mincodex

Problem: `@th3_m0l3` hatte parallel aktive feste `postfast:*`-Direktjobs und Queue-Dispatch-Jobs; dadurch blieb Doppelpost-/Drift-Gefahr bestehen, und Time-Critical-Drafts gingen noch zu grosszuegig via Telegram raus

Ursache: Mehrere Scheduler-Quellen fuetterten denselben PostFast-Versandweg; der Dispatcher konnte weder sprachspezifisch filtern noch `ready`-Items nach Qualitaet priorisieren, und `public-news-to-queue.mjs` hatte kein konservatives urgentes Telegram-Gate

Fix: Alle festen `postfast:*`-Jobs pausiert, Queue-first Slots auf `09:15`, `15:45 EN` und `18:30` umgestellt, `postfast-dispatch.mjs` um `--language` + Relevance/Recency-Priorisierung erweitert und `public-news-to-queue.mjs` auf strengere Time-Critical-Flags + Telegram nur bei sauberem Fact-Check gezogen; Dry-Runs fuer alle drei Slots erfolgreich

PostFast / Queue Drift

~30 mincodex

Problem: Lokale `tweet-queue.json` konnte alte `scheduled_for`-Reste, past-due `scheduled` ohne `postfastId` und fehlende Remote-Schedules behalten, obwohl in PostFast bereits nichts mehr dafuer existierte

Ursache: `postfast-dispatch.mjs` hatte zwar einen read-only `--sync-report`, aber keinen lokalen Apply-/Repair-Pfad; dadurch blieb erkannter Drift als Diagnose stehen und wurde nie in die Queue zurueckgeschrieben

Fix: `--repair` in `scripts/postfast-dispatch.mjs` gebaut, konservative lokale Write-Back-Regeln fuer verwaiste Schedules / missing-remote / sichere `postfastId`-Backfills ergänzt und live 5 Queue-Faelle bereinigt; anschliessender Sync-Report war fuer `@th3_m0l3` wieder sauber (`scheduledItems=0`, `missingInPostFast=0`)

Night Action / Recovery + Doppeltrigger

~30 mincodex

Problem: Das 03:30-Fallback war noch kein echter Lane-Recovery-Pfad, der finale Night-Status konnte echte Fails trotzdem als `success` beenden, und deaktivierte Night-Action-Altjobs lagen weiter in `cron/jobs.json` herum

Ursache: `nightaction-execute.sh` kannte keinen selektiven Recovery-Modus mit Merge zurueck in den Tagesstatus; der Abschluss schrieb am Ende zu pauschal Erfolg; die frueheren Agent-Cron-Eintraege waren zwar disabled, aber noch als zweite potentielle Triggerquelle im Scheduler-File vorhanden

Fix: 03:30-Recovery als eigene systemd-Unit/Timer ergaenzt, `nightaction-execute.sh` auf kritische Task-Recovery + Feedback-Merge + ehrlichen finalen `fail` umgestellt, isolierte Recovery-/Fail-Smokes erfolgreich gefahren und die Night-Action-Altjobs `nightaction:plan`/`nightaction:execute` komplett aus `.openclaw/cron/jobs.json` entfernt

Night Action / Smoke Coverage + X Scraper Locking

~35 mincodex

Problem: Fuer `NA-17` fehlten noch die expliziten Szenarien `report-only-Fail` und `Queue-Noop`; ausserdem kollidierten parallele X-Scraper-Runs weiter erst spaet ueber Playwrights Browser-Profil-Lock

Ursache: Es gab keinen wiederverwendbaren Smoke-Harness fuer `run_with_capture()`/Status-Metriken, und `x-scraper-playwright.mjs` verliess sich nur auf den spaeten `SingletonLock` des Browsers statt auf einen fruehen, klaren Prozess-Lock

Fix: `nightaction-execute.sh` source-only-faehig gemacht, `nightaction-smoke-tests.sh` fuer `report-only-Fail` + `Queue-Noop` hinzugefuegt und erfolgreich gefahren; zusaetzlich fruehen X-Scraper-Lock mit Retry/Stale-Cleanup vor Browser-Start eingebaut und per kuenstlichem Lock + Live-Profile-Smoke verifiziert

Night Action / Status Snapshot

~25 mincodex

Problem: Der kanonische Night-Status spiegelte den 2026-03-27-Run nicht ehrlich: `NA-DATA-001/002` blieben im Snapshot bei `command_ok`, Morning-Readiness fehlte komplett, und `nightaction.md` referenzierte teils einen spaeteren Lock-SKIP statt des Execute-Laufs

Ursache: `nightaction-status.py` uebernahm zwar Plan/Logs, wertete aber weder Queue-/Scrape-Metriken aus noch ueberschrieb es harmlose Success-Reasons bei spaeten Output-Fails; beim Markdown-Rueckblick wurde einfach die letzte passende Tageszeile gezogen

Fix: Morning-Readiness-Metriken (`critical_tasks_passed`, `scraped_tweets`, `queue_delta`, `morning_post_ready`) in den Status eingebaut, Output-Fails im Snapshot auf `failed/output_failure_signal` umgestellt, `nightaction.md`-Lookup auf `EXECUTE` priorisiert und den 2026-03-27-Status neu geschrieben/verifiziert

Night Action / X Data Lane

~45 mincodex

Problem: Night-Action konnte X-Data-Tasks weiter falsch-gruen melden; zusaetzlich war der Night-Plan noch auf ein nicht vorhandenes `chrome`-Binary verdrahtet und der Watchlist-Scraper scheiterte beim Supabase-Write an `_watchlist_label`

Ursache: Command-Runner validierte Exit-0-Logs nicht robust genug, claimed files wurden nicht gegengeprueft, Browser-/Supabase-Signale waren nicht ueberall als Hard-Fail bekannt, `build-night-plan.py` erzwang weiter `X_BROWSER_CHANNEL=chrome`, und `x-scraper-playwright.mjs` upsertete interne `_`-Hilfsfelder mit in `x_tweets`

Fix: Night-Action-Soft-Fail-Erkennung mit Output-Quiescence + `claimed_files_missing` erweitert, Browser-/Supabase-Signale auch in Head-Review und Quality-Gate uebernommen, Night-Plan-Builder/aktuellen Tagesplan auf Playwright-Fallback ohne `chrome` umgestellt und `_watchlist_label` vor dem Supabase-Upsert entfernt; helper-smoke plus Live-Watchlist-Run erfolgreich

Agent System / OpenClaw Compaction

~15 mincodex

Problem: OpenClaw compactete fast nach jedem Input und schrieb wiederholt `Compaction safeguard: no real conversation messages to summarize` ins Gateway-Journal

Ursache: In `openclaw.json` stand `contextTokens=64000`, aber `compaction.reserveTokensFloor=170000`; die Reserve war groesser als das gesamte konfigurierte Kontextfenster

Fix: `reserveTokensFloor` auf `20000` abgesenkt, Gateway neu gestartet, Dummy-Agent-Run und Health erfolgreich verifiziert

Agent System / Bubblewrap

~5 mincodex

Problem: Codex warnte im Terminal, dass kein System-`bubblewrap` unter `/usr/bin/bwrap` vorhanden sei und deshalb auf die vendored Variante zurueckfalle

Ursache: Das Ubuntu-Paket `bubblewrap` war auf dem neuen Server noch nicht installiert

Fix: `sudo apt-get install -y bubblewrap` ausgefuehrt und `bwrap`/`codex` danach erfolgreich verifiziert

Agent System / Codex Aliases

~5 mincodex

Problem: `cdxg` und `cdxy` zeigten im Terminal noch auf veraltete Codex-Schalter und ein nicht existentes `godmode`-Profil

Ursache: `.bashrc` enthielt historische Alias-Definitionen aus einer älteren Codex-CLI-Generation; die aktuelle `config.toml` definiert kein Profil `godmode`

Fix: Aliase auf aktuelle Flags umgestellt: `cdxo` -> `codex`, `cdxg` -> `codex --full-auto`, `cdxy` -> `codex --dangerously-bypass-approvals-and-sandbox`; interaktiv verifiziert

Agent System / Codex CLI

~10 mincodex

Problem: `codex` war im normalen SSH-Terminal nicht aufrufbar, obwohl das Binary auf dem Server vorhanden war

Ursache: Das Binary lag nur im versionierten VS-Code-Extension-Pfad und nicht an einem stabilen Ort im normalen Shell-PATH

Fix: Stabilen Wrapper unter `~/.local/bin/codex` angelegt, der das aktuelle Extension-Binary aufloest; in frischer Login-Shell verifiziert

Google / GOG OAuth

~20 mincodex

Problem: Der Gmail-Push-Watcher im Gateway und direkte `gog`-Google-Calls auf dem neuen Server fielen mit `invalid_grant` aus

Ursache: Der auf den neuen Host uebernommene `gog`-Refresh-Token war abgelaufen bzw. von Google widerrufen

Fix: `gog auth add --manual --force-consent` neu durchgezogen, frischen Token gespeichert, Gateway neu gestartet und Gmail-Watcher/Drive/Gmail live verifiziert

Server Migration / Tailscale Funnel

~5 mincodex

Problem: Der alte Server publizierte den Gmail-Push-Pfad trotz gestoppter Dienste noch weiter per Tailscale Funnel; damit war die Hook-URL doppelt verdrahtet

Ursache: `tailscale funnel` lebt unabhaengig von `systemd`-Units und war auf dem Altserver nach dem Cutover nicht zurueckgesetzt worden

Fix: Altserver-Funnel per `tailscale funnel reset` entfernt und anschliessend verifiziert: neuer Host haelt `/gmail-push-5f4b3181`, alter Host zeigt `No serve config`

Server Migration / TLI Gmail Hook

~35 mincodex

Problem: Der neue Server hatte keinen produktiven 4h-TLI-Hook, waehrend der Altserver die letzte funktionierende Mail-Verarbeitung trug; zusaetzlich schlug `log-intake` im Hook weiter still fehl

Ursache: Die produktive User-Crontab war nie auf den neuen Host umgezogen; `tli-gmail-hook-v2.mjs` rief intern blind `node log-intake.mjs` auf und scheiterte im Cron-Kontext am PATH

Fix: TLI-Hook-Cron auf dem neuen Server aktiviert, Hook auf `process.execPath`/`execFileSync` umgestellt, Live-Run erfolgreich (5 Mails verarbeitet, unread danach 0), Altserver-Crontab entfernt

Server Migration / X Analytics Cron

~20 mincodex

Problem: Der neue Server konnte den X-Analytics-Job nicht starten und haette den Altserver weiter als einzige produktive Instanz gebraucht

Ursache: `x-analytics-cron.sh` erzwang `X_BROWSER_CHANNEL=chrome`, aber auf dem neuen Server war kein System-Chrome unter `/opt/google/chrome/chrome` vorhanden; der CSV-Import nutzte intern zudem blind `node`

Fix: Browser-Fallback auf lokale Chromium-Binaries bzw. Playwright bundled Chromium eingebaut, Import in `x-analytics-download.mjs` auf `process.execPath`/`execFileSync` umgestellt, Live-Run erfolgreich (Summary + 395 Posts importiert)

VS Code / Copilot Chat Agents

~10 mincodex

Problem: Die Problem-Ansicht auf dem neuen Server zeigte veraltete Unknown-Model/Unknown-Tool-Warnungen fuer die Copilot-Agent-Dateien

Ursache: Die globalStorage-`*.agent.md` Dateien referenzierten nicht mehr verfuegbare GitHub-Tools und ein altes Gemini-Preview-Modell

Fix: Unsupported-Frontmatter in `Ask.agent.md`, `Explore.agent.md` und `Plan.agent.md` entfernt; Problems-Trigger danach leer

OpenClaw Gateway / Server-Migration

~15 minantigravity

Problem: Gateway crashte im Endlos-Restart-Loop (197+ Restarts) auf dem neuen Hetzner CAX31 ARM64 Server; Tailscale war logged out; Service-File-Label zeigte falsche Version

Ursache: `openclaw.json` enthielt `compaction` Keys in `agents.list[0]` (main) und `agents.list[1]` (doug), die von OpenClaw v2026.3.24 nicht mehr akzeptiert werden; Tailscale war nach Server-Neuaufsetzen noch nicht eingeloggt; Service-File-Description sagte v2026.3.7 statt v2026.3.24

Fix: `compaction` Keys aus `agents.list` entfernt, Gateway neugestartet (healthy: `{\"ok\":true,\"status\":\"live\"}`), Tailscale eingeloggt + `--operator=openclaw` gesetzt (Funnel funktioniert), Service-File-Label auf v2026.3.24 korrigiert, daemon-reload ausgefuehrt

OpenClaw Gateway / Telegram Groups

~25 mincodex

Problem: Tyrone antwortete in Gruppen weiter nicht verlaesslich, obwohl `groupAllowFrom` schon gesetzt war

Ursache: Die Telegram-Konfiguration hatte noch keine explizite `channels.telegram.groups`-Route; `openclaw doctor` bewertete den Bot dadurch weiter als Gruppen-Setup im Blockiermodus. Parallel war fuer `@EPalazzo_bot` zunaechst `can_read_all_group_messages=false`, also Privacy-Mode aktiv

Fix: `channels.telegram.groups` zuerst mit Wildcard-Route plus `allowFrom=8424800642` und `requireMention=false` ergaenzt, danach auf die echte Gruppe `-5282701263` verengt, Gateway neu gestartet und Telegram-Privacy-Wechsel verifiziert; `getMe` zeigt jetzt `can_read_all_group_messages=true`, der Gruppenpfad ist live und bleibt weiter nur auf Dominiks Sender-ID begrenzt