DevSecOps Digest
Щоденний DevSecOps дайджест

OpenClaw щодня: direct tool API, безпечні файли і delivery reliability

openclaw · 2026-06-20

Головний кут дня: OpenClaw варто сприймати не тільки як чат до агента, а як локальний control plane з чіткими межами: хто може викликати інструмент, що можна змінювати на диску, як не втратити відповідь після рестарту і де Docker-інсталяція має операційні поручні.

1. Direct tool API: корисно, але це операторський інтерфейс

POST /tools/invoke дає змогу викликати один інструмент напряму без повного agent turn. Практичний сценарій: внутрішній dashboard натискає кнопку “покажи активні сесії”, “запусти health snapshot”, “надішли повідомлення в відомий канал” — і все проходить через Gateway auth та tool policy.

Сильний патерн: тримати цей endpoint тільки на loopback, tailnet або приватному ingress. Bearer token тут — не “трохи доступу”, а операторський ключ до gateway. Якщо треба дати різні рівні довіри різним системам, краще підняти окремий gateway/OS-user, а не намагатися зробити shared secret багатокористувацькою IAM-системою.

2. Файли: guardrail не дорівнює sandbox

secure file operations добре показує правильний тон для agentic систем: OpenClaw використовує @openclaw/fs-safe для root-bounded reads/writes, atomic replacement, archive limits і secret-file handling, але прямо не продає це як sandbox.

Практична конфігураційна ідея:

  • для домашнього gateway лишити OPENCLAW_FS_SAFE_PYTHON_MODE=off і покладатися на Node-safe path;
  • для shared host, де інші процеси того самого UID можуть міняти директорії, перейти на OPENCLAW_FS_SAFE_PYTHON_MODE=require;
  • для hostile local-user isolation не латати це env-прапорцем, а розділяти gateway по OS users, контейнерах або VM.

3. Delivery reliability: “send” має бути durable, не випадковий side effect

Message lifecycle refactor — важливий архітектурний документ. Суть: receive і send мають бути окремими lifecycle primitives; reply — лише relation; фінальна видима відповідь має мати durable intent до platform send.

Це не косметика. Типова failure mode: Telegram update уже acked, модель згенерувала відповідь, процес упав перед sendMessage, користувач нічого не отримав. Правильний дизайн — at-least-once recovery з receipt/idempotency там, де канал це дозволяє.

4. Streaming: прогрес без token-spam

Streaming and chunking корисний для UX-дизайну каналів. OpenClaw розділяє block streaming і preview streaming: канал отримує завершені блоки або editable preview, а не сирі token deltas.

Практичний варіант для робочих чатів:

{
  agents: {
    defaults: {
      blockStreamingDefault: "on",
      blockStreamingBreak: "message_end",
      blockStreamingChunk: { minChars: 1200, maxChars: 3500, breakPreference: "paragraph" },
      blockStreamingCoalesce: { idleMs: 1200, minChars: 1500 }
    }
  },
  channels: {
    slack: { streaming: { mode: "progress" } },
    telegram: { streaming: { mode: "partial" } }
  }
}

Ідея проста: показувати прогрес там, де це доречно, але не перетворювати груповий чат на потік дрібних фрагментів.

5. Операційні дрібниці, які зменшують хаос

  • Gateway lock: один gateway на порт, швидкий fail при EADDRINUSE, без stale lock drama після crash/SIGKILL.
  • ClawDock: нормальний thin-wrapper для Docker-операцій — clawdock-status, clawdock-logs, clawdock-dashboard, clawdock-show-config з redaction.
  • Prometheus metric naming: якщо виводити свої метрики навколо OpenClaw, тримати одиниці, суфікси й label-cardinality дисципліновано.

6. 10 практичних use cases на сьогодні

  1. Internal “agent ops” dashboard, який викликає тільки read-only tools через /tools/invoke.
  2. Separate gateway для небезпечних tool lanes замість одного gateway з хитрою allowlist-магiєю.
  3. Docker-based personal assistant із ClawDock як щоденним runbook CLI.
  4. Secure upload lane: agent приймає архіви, але extraction має size, entry і link limits.
  5. Slack progress previews для довгих аналізів без засмічення каналу.
  6. Telegram partial preview для коротких мобільних відповідей.
  7. Failure drill: примусово перезапустити gateway під час outbound send і перевірити, чи відповідь не губиться.
  8. “No public metrics” правило: Prometheus scrape тільки через operator-auth або приватну мережу.
  9. Staging gateway на окремому порту для тесту нових plugins і channels.
  10. Runbook пункт: якщо gateway не стартує, спершу перевірити lock/port conflict, а не перебирати моделі.

Що подивитися