Samstag, 2. Mai 2026

Problem: Telegram `/status` zeigte weiter `dashscope-coding/qwen3.5-plus`, und echte OpenAI-Codex-Cron-Smokes liefen zunaechst in ein ChatGPT-Usage-Limit

Ursache: Persistierte `agent:main:main` Session-Overrides sowie weitere `openclaw.json` Modell-Overrides waren noch auf DashScope; parallel war der ChatGPT/Codex-Usage-Bucket bis `` erschoepft

Fix: Session-Overrides bereinigt, Subagent-/Agent-/Gmail-Hook-Modelle auf `openai-codex/gpt-5.5` gezogen, Gateway sauber neu gestartet, Codex-Reset abgewartet und echte Cron-Smokes fuer `public-news-refill`, `sec-insider-alerts` und `clawledge:mention-scan` erfolgreich mit `openai-codex/gpt-5.5` verifiziert

Problem: OpenClaw Default war zwar auf `openai-codex/gpt-5.5`, aber aktive Cron-Payloads, Agent-Heartbeats, Fallbacks und der alte Tyrone/Python-LLM-Client konnten weiter DashScope/Kimi/Qwen nutzen

Ursache: Mehrere Routing-Schichten waren getrennt: `jobs.json` Payload-Overrides, `openclaw.json` Heartbeat/Fallbacks und `workspace/agents/llm_client.py` als eigener DashScope-Client

Fix: 35/35 aktive AgentTurn-Crons auf `openai-codex/gpt-5.5`, Heartbeats und Fallbacks in `openclaw.json` auf ChatGPT/Codex, Python-Agent-Client auf `codex exec -m gpt-5.5` mit Legacy-Modellmapping umgestellt, Gateway hot-reload/restart verifiziert (`health ok`, Telegram connected, 0 aktive Tasks)

Problem: 7/35 aktivierte OpenClaw-Crons blieben rot und manuelle AgentTurn-Smokes blockierten wiederholt Gateway-WS/Health

Ursache: Deterministische Script-Crons laufen ueber den Embedded-AgentTurn-Pfad; Bootstrap/System-Prompt/Tool-Bundling und Modell-Fetch blockieren den Node-Event-Loop, direkte Scripts selbst sind schnell

Fix: Rote Scripts direkt verifiziert, betroffene OpenClaw-Crons auf `qwen3.5-plus`/`thinking=off`/`lightContext=true`/`toolsAllow=exec` gehaertet, Gateway nach haengenden Runs wiederhergestellt, OS-Crontab-Fallbacks fuer PostFast und X-Scraper auf direkte Guard-/Wrapper-Scripts repariert

Problem: OpenClaw konnte `openai-codex` global nicht produktiv nutzen; alter Profileintrag meldete `expired`/`refresh_token_reused`

Ursache: Der bisherige ChatGPT/OAuth-Refresh-Pfad war abgelaufen bzw. wiederverwendet; Codex-CLI-Login und OpenClaw-embedded Auth sind getrennte Stores

Fix: Browser-OAuth neu durchgezogen, neuen Profileintrag `openai-codex:[E-Mail]` als `ok` gesetzt, Default auf `openai-codex/gpt-5.5` gestellt, Agent-Smoke `OPENCLAW_CODEX_AUTH_OK` verifiziert und Gateway danach final neu gestartet (`health ok`, Telegram connected)

Problem: `config.incubator.yaml` war dokumentiert, aber systemd/Web-GUI und `/idea` nutzten weiter teilweise `messages.db`; Multi-Target wurde vom Loop-Guard blockiert; Web-GUI war nur lokal gebunden

Ursache: Services hatten keinen expliziten Config-Pfad; Similarity-Check prüfte nur pro Sender statt pro Sender-Ziel-Paar; Access-Strategie war offen

Fix: Listener/Web-GUI/`bridge-idea-intake.sh` auf Incubator-Bus gezogen, Loop-Guard zielbezogen gemacht, `bridge cleanup` ergänzt, Web-GUI tailnet-only auf `[internal]` gebunden und Multi-Target-Smoke verifiziert

Problem: Nach Tests/`cron list` wurde der Gateway erneut langsam: `health` nur nach ~24s, `/status` zeitweise nicht reachable

Ursache: Ein Embedded-Nachlauf blockierte den alten Node-Event-Loop; systemd konnte den Prozess beim Stop erst nach Timeout per SIGKILL beenden

Fix: Gateway gezielt neu gestartet, Warm-up abgewartet; final `health ok`, Telegram running, `/status` reachable, `0` aktive Tasks

Problem: `/idea --to codex` belegte bisher nur Inbox-Zustellung und keine echte Codex-Ausführung; erster Runner-Smoke fand im systemd-Kontext außerdem `codex` nicht im PATH

Ursache: `CodexWorker` war V1-only, systemd hat nicht die interaktive Shell-PATH-Konfiguration

Fix: Codex-Runner mit absolutem CLI-Pfad, read-only Sandbox, JSONL-Runlog und Bridge-Rückantwort implementiert; systemd-Listener neu gestartet; Smoke `CODEX_BRIDGE_OK` erfolgreich

Problem: X-Auto-Post-Crons konnten trotz X-Preflight-Regel ohne expliziten Guard starten und über Kimi/Lane-Timeouts die Gateway-Liveness belasten

Ursache: Morning/US-Open-Payloads waren LLM-lastig, ohne direkten `x-rate-check.sh`-Guard und mit `kimi-k2.5` als Modell

Fix: `x-auto-post-guard.sh` gebaut, Morning/US-Open/Evening-Crons auf Guard, `qwen3.5-plus`, `thinking=off`, `lightContext=true` und Dispatch-Timeout umgestellt; JSON und Fake-Dispatch verifiziert

Problem: Direkt nach dem Gateway-Restart blockierte ein automatisch gestarteter X-Auto-Post-Cron erneut die Gateway-WS-Reachability

Ursache: Cron-Runtime startete `twitter:auto-post-morning`; Task-Cancel wird fuer Cron-Runtimes noch nicht unterstützt und der Embedded-Run lief in den Lane-Timeout

Fix: Task bis zum eigenen Timeout beobachtet, danach `0` aktive Tasks, `openclaw status` wieder erreichbar; X-Rate-Check aktualisiert (`39999/40000` search remaining)

Problem: Nach dem Update war der Gateway-Service zwar `active`, aber Health-/Status-WS-Checks liefen zeitweise in Timeouts

Ursache: Nachgeholte Cron-/Embedded-Agent-Runs blockierten den Node-Event-Loop; Kimi `thinking_budget`/`max_completion_tokens`-Schemafehler und Timeouts triggerten Fallback-Kaskaden

Fix: Gateway per systemd-User-Service gezielt neu gestartet; danach `openclaw health --json` wieder `ok: true` und `/status` erreichbar auf `2026.4.29`

Problem: Der nicht-interaktive OpenClaw-Updater blieb nach dem Gateway-Neustart still im Nachlauf hängen

Ursache: Post-Update-Wrapper/Doctor-Nachlauf beendete sich nicht, obwohl der Gateway bereits wieder auf `2026.4.29` aktiv war

Fix: Wrapper-Prozesse kontrolliert beendet, Gateway-Servicezustand und `/status`/`health` geprüft; OpenClaw läuft auf `2026.4.29` weiter

Problem: Automatische Agent-Fallbacks wurden nur auf stdout gemeldet und waren für die 7-Tage-Auswertung nicht persistent auswertbar

Ursache: `llm_client.py` hatte keinen JSONL-Logger für Modellwechsel und fing primär nur Timeout-Klassen ab

Fix: JSONL-Event-Logger nach `memory/model-fallbacks.jsonl` ergänzt, HTTP-/Modellfehler in den Fallback-Pfad aufgenommen und Serialisierung plus `py_compile` verifiziert