2f4d4751e5
Related: #162391 ## What Problem This Solves Fixes two follow-ups to #162391: - A scheduled run that hands its work to a subagent can deliver the child's `AUTOMATION_FAILED` reply verbatim and still record the run as `ok`. This happens on announce jobs, and on `delivery: none` jobs since #162474 started recording the child's answer. - A silent (`delivery: none`) job whose agent keeps reporting a blocked task gets auto-disabled after 10 runs, and that posts an auto-disable notice even though the job has nowhere to notify. ## User Impact - When a delegated run's settled child answer starts with `AUTOMATION_FAILED`, the run is recorded as an error with the child's explanation. Announce and current-session delivery send only the explanation, never the token. `delivery: none` runs record it without sending anything, and keep the run transcript as other failed executions do. - A `delivery: none` job with no failure-alert route still records agent-reported failures in run history, job status, and error backoff (escalating to hourly, like any failing job). Those failures never auto-disable the job or post the auto-disable notice, so the job stays silent. - Unchanged: - Runtime errors on silent jobs still auto-disable at 10 as before. - Announce and webhook jobs, and jobs with a configured failure route, still auto-disable on agent-reported failures. - `NO_REPLY` behavior. ## Why This Change Was Made - **Settled child answers.** #162391 classified the token in `resolveCronPayloadOutcome`, which runs on the parent's reply before #117308's descendant settlement. Two places in `dispatchCronDelivery` then adopt the settled child's reply as the run's answer: the announce settlement (#117308) and the no-delivery settlement (#162474). Neither classified it. Both now go through one adoption helper that calls the shared parser `readAutomationFailedReport`, so the run's effective terminal answer is classified after settlement. `buildDeliveryState` derives one execution-failed flag from that result and uses it for both the completion status and the transcript-cleanup decision, so a failed no-delivery run is no longer cleaned up as a quiet success. `run-finalize` consumes the result the same way it already handles `pendingPresentationWarningError`: error status, permanent classification, explanation as the summary. - **Auto-disable.** Maintainer decision: an agent-reported blocked outcome on a job with no notification owner must not lead to auto-disable. The permanent error classification now carries `reportedByAgent`. `applyJobResult` in `timer-outcomes.ts` still counts every error in `consecutiveErrors`, so status and error backoff are unchanged. It skips only the auto-disable decision, and only when all of these hold: the failure was agent-reported, `resolveFailureAlert` finds no route, and the delivery mode is `none` (webhook jobs still auto-disable). - Hermes handles the same protocol the same way (`[CRON_FAILURE]`): its cron hint asks the agent to report a delegated child's failure on the first line. No new tool is needed. ## Bounded cost - No new turns, runs, waits, or notifications. Parsing happens once per settled answer inside the existing finalization. - Agent-reported failures stay permanent, so the scheduler never retries them early. - A silent blocked job keeps the normal error backoff (30 s, 1 min, 5 min, 15 min, then hourly), so it can never run more often than an identical job on origin/main. The only difference is that it keeps running at that backed-off cadence after the 10th failure instead of being disabled. ## Evidence ### Live model, Telegram Test Server (`telegram-e2e-userbot`, DM) Setup: the repo runner unchanged (`run-mock-sut-user-e2e.mjs --backend mock --source-gateway --dm`, Convex lease). `E2E_MOCK_SERVER_PATH` points to a throwaway proxy that stands in for the mock provider and forwards every request unchanged to the real OpenAI API. The proxy reads the key from a private file, so the Gateway only ever holds the runner's dummy key. `E2E_ROOT_CONFIG_PATCH` selects `openai/gpt-6-astra` (`tools.toolSearch: false`). A scenario `command` step creates the jobs with `openclaw automations add` and runs them. No model output was steered: the live parent chose `sessions_spawn`, and the live child and the live silent job wrote their own `AUTOMATION_FAILED` reports because they had no shell tool. The only steer is timing in case (b): before each run, `cron.update` sets `nextRunAtMs` to now and moves `lastRunAtMs` back 2 h, so the error backoff (up to 1 h) counts as served. The Gateway's own scheduler then runs the job as a normal scheduled (not forced) run. Before = origin/main ` |
||
|---|---|---|
| .agents | ||
| .claude | ||
| .github | ||
| .openclaw/worktree-profiles | ||
| .vscode | ||
| apps | ||
| CHANGELOG | ||
| config | ||
| crates | ||
| custodian-skills | ||
| deploy | ||
| docs | ||
| examples/ai-chat | ||
| extensions | ||
| git-hooks | ||
| packages | ||
| patches | ||
| qa | ||
| scripts | ||
| security | ||
| skills | ||
| src | ||
| test | ||
| ui | ||
| .crabbox.yaml | ||
| .dockerignore | ||
| .env.example | ||
| .gitattributes | ||
| .gitignore | ||
| .npmrc | ||
| .oxfmtrc.jsonc | ||
| .oxlintrc.json | ||
| .pre-commit-config.yaml | ||
| .semgrepignore | ||
| AGENTS.md | ||
| appcast-arm64.xml | ||
| appcast-x86_64.xml | ||
| appcast.xml | ||
| CHANGELOG.md | ||
| cli-root-options.d.mts | ||
| cli-root-options.mjs | ||
| CONTRIBUTING.md | ||
| docker-compose.yml | ||
| docker-entrypoint.mjs | ||
| Dockerfile | ||
| fly.toml | ||
| gateway-run-argv.d.mts | ||
| gateway-run-argv.mjs | ||
| gateway-shutdown-budget.d.mts | ||
| gateway-shutdown-budget.mjs | ||
| LICENSE | ||
| node-compile-cache.d.mts | ||
| node-compile-cache.mjs | ||
| node-host-launcher.mjs | ||
| node-runtime-recovery.d.mts | ||
| node-runtime-recovery.mjs | ||
| node-runtime-update.d.mts | ||
| node-runtime-update.mjs | ||
| node-sqlite.d.mts | ||
| node-sqlite.mjs | ||
| node-version.d.mts | ||
| node-version.mjs | ||
| openclaw.mjs | ||
| package.json | ||
| pnpm-lock.yaml | ||
| pnpm-workspace.yaml | ||
| README.md | ||
| render.yaml | ||
| SECURITY.md | ||
| taxonomy.yaml | ||
| THIRD_PARTY_NOTICES.md | ||
| tsconfig.core.json | ||
| tsconfig.extensions.json | ||
| tsconfig.extensions.projects.json | ||
| tsconfig.json | ||
| tsconfig.scripts.json | ||
| tsconfig.ui.json | ||
| tsdown.ai.config.ts | ||
| tsdown.config.ts | ||
| VISION.md | ||
| vitest.config.ts | ||
OpenClaw 🦞 — Your assistant, on your devices, in your chats
OpenClaw is an open-source AI assistant that runs on your own computer and meets you in the channels you already use: Discord, iMessage, Slack, Teams, Telegram, WhatsApp, and 20+ more, plus native apps for macOS, iOS, Android, Windows, and Linux. One Gateway runs it as a personal assistant on a laptop or as a shared team deployment; configuration is the only difference.
Yours, with no catch. State, memory, and credentials live on your hardware. Models and agent harnesses (Claude, Codex, local models) are plugins you can swap without changing anything else. Your prompts go to the model provider and chat platforms you configure, plus any diagnostics export you enable yourself; by default OpenClaw itself phones home for nothing but a daily version check, anonymous feature statistics are opt-in, and update.checkOnStart: false disables both (what OpenClaw sends). OpenClaw is stewarded by the OpenClaw Foundation, an independent 501(c)(3), and has no paid tier, hosted service, or token. The architecture case — trusted gateway, untrusted execution, deterministic policy — is in Why OpenClaw.
Website · Docs · Getting started · Why OpenClaw · FAQ · Vision · DeepWiki
Install
The installer supports macOS, Linux, and Windows. It provisions a supported Node.js runtime when needed.
# macOS / Linux / WSL2
curl -fsSL https://openclaw.ai/install.sh | bash
# Windows PowerShell
iwr -useb https://openclaw.ai/install.ps1 | iex
Already manage Node.js? Install the published package instead (Node 24.16+ or 26.1+; Node 26 recommended):
npm install -g openclaw@latest --allow-scripts=openclaw
That command is for npm 12 or npm 11.16+. On npm 11.15 and earlier, omit
--allow-scripts=openclaw. See the
installation guide for the lifecycle script
contract, Docker, Nix, and other deployment paths.
Quick start
On a fresh install, the installer scripts start onboarding automatically. Complete the wizard they open. If you installed the package directly with npm, pnpm, or Bun, run:
openclaw onboard --install-daemon
After onboarding:
openclaw gateway status
openclaw dashboard
Onboarding verifies model access, creates the workspace, and configures the Gateway. The last command opens the Control UI; send a message there to confirm the assistant is working. See the getting started guide for channel setup and troubleshooting.
How it fits together
- The Gateway is the local control plane for sessions, tools, events, and channel connections.
- The Control UI, CLI, and TUI connect to the Gateway.
- Channels bring the assistant to WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage, and other messaging services.
- Companion apps and nodes add voice, Canvas, camera, screen, and device-local actions on supported platforms.
OpenClaw works with hosted and local model providers. Its tools, skills, and plugins extend what an assistant can do.
Security
Treat inbound messages as untrusted input. DM-capable channels pair unknown senders by default; approve a pairing request with openclaw pairing approve <channel> <code>.
Tools run on the host for the main session unless you configure sandboxing. Read the security guide, exposure runbook, and sandboxing guide before connecting other users or exposing the Gateway remotely.
Documentation
| Goal | Start here |
|---|---|
| Configure models and auth | Models · Model providers |
| Connect a messaging service | Channels |
| Add tools, skills, and plugins | Tools · Skills · Plugins · ClawHub |
| Run apps and device nodes | Platforms · Nodes |
| Use the CLI and chat commands | CLI reference · Slash commands |
| Configure or operate the Gateway | Configuration · Architecture · Updating · Release channels |
Development
The repository is a pnpm workspace. Plain npm install at the repository root is not supported.
git clone https://github.com/openclaw/openclaw.git
cd openclaw
pnpm install
pnpm build
pnpm ui:build
See CONTRIBUTING.md for the contribution workflow and the source setup guide for the development loop.
Governance
OpenClaw is developed in the open by the OpenClaw Foundation, an independent 501(c)(3). The Foundation employs the core team and signs releases. Donors and infrastructure sponsors support the Foundation; none of them own or direct the project. OpenAI is a donor, not an owner.
Community
See CONTRIBUTING.md for maintainers and contribution guidelines; AI-assisted PRs are welcome.
Use the issue chooser for bugs and feature requests, ask setup questions in Discord, and report vulnerabilities through SECURITY.md. New capabilities usually belong in plugins built on the plugin SDK and shared through ClawHub.
OpenClaw was built for Molty, a space lobster AI assistant, by Peter Steinberger and the community. Explore the project lore, soul.md, Peter's site, Star History, and @openclaw.
Special thanks to Mario Zechner for his support and for pi, and to Adam Doppelt for the lobster.bot domain.
Donors and sponsors
The Foundation is funded by donors including Amazon, Lobster Computer Company, Offline Holdings, OpenAI, Red Hat, and the University of Michigan, with infrastructure support from Blacksmith, Convex, GitHub, NVIDIA, and Vercel.
 |
 |
 |
 |
 |
 |
 |
Contributors
Thanks to all clawtributors:
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?v=4&s=48){kind=small}
![clawdinator[bot]](https://avatars.githubusercontent.com/in/2607181?v=4&s=48){kind=small}
![google-labs-jules[bot]](https://avatars.githubusercontent.com/in/842251?v=4&s=48){kind=small}
License
MIT © OpenClaw Foundation. See THIRD_PARTY_NOTICES.md for incorporated or adapted code.