Nanobot
Nanobot separates notification delivery from model execution
Nanobot’s event-bus work gives scoped notifications one delivery path, while a separate signed-webhook proposal sends deterministic messages without invoking a model. Remote project-selection work draws a related line between choosing a server workspace and granting local full access.
A monitoring alert does not need an agent to decide that it should be delivered. The signed-webhook proposal accepts a strict content payload and routes it to the existing outbound message bus. It neither accepts a user-selected recipient nor turns the notification into an inbound conversation. That is an architectural distinction: deterministic systems can reuse channel delivery without buying a model call or giving notification text an opportunity to become an instruction.
The broader event work addresses the internal side of the same problem. Local event handlers are awaited separately from queued network delivery; progress, file-edit output and compaction events receive an operation-scoped sender. Slow destinations are isolated by channel and chat identity. The change says persisted session and wire formats stay compatible, and it does not invent a second notification store or transport.
The facts
- PR #5652 proposes a disabled-by-default listener that publishes outbound notification text without entering AgentLoop. - The proposed webhook fixes channel and chatId in configuration, so callers cannot choose a destination. - Authentication covers timestamp, request ID and raw body with HMAC-SHA256; freshness, replay, body-size and rate limits are explicit. - PR #5670 routes typed events through MessageBus, preserving per-destination FIFO while allowing different chats to progress concurrently. - PR #5673 treats remote project selection, a native folder picker and Full Access as distinct capabilities, including through a loopback reverse proxy.
Why it matters
As agents become services, users need reliable delivery even when no reasoning is required. A single event contract also makes WebUI and terminal clients less likely to disagree about whether compaction ended or a retry is still running. The remote workspace proposal adds a useful parallel: selecting a path on the server must not open a file chooser on the browser’s machine or grant Full Access merely because a reverse proxy connects through loopback. Capability and transport location are different facts.
Current
Inspected on 2026-09-06. The Nanobot stable-release baseline is v0.3.0 published 2026-07-25T08:08:47Z. The main source was open when captured. Release metadata is a version boundary, not evidence that an open proposal has shipped.
Evidence
The primary source is HKUDS/nanobot PR #5652 (https://github.com/HKUDS/nanobot/pull/5652). Supporting context comes from HKUDS/nanobot PR #5670 (https://github.com/HKUDS/nanobot/pull/5670); HKUDS/nanobot PR #5673 (https://github.com/HKUDS/nanobot/pull/5673). The linked records were inspected directly; related project records are not independent confirmations.
Operator take
For deterministic notifications, validate replay rejection and destination pinning before enabling a listener. For runtime events, disconnect a client during a terminal transition and check that reconnecting reconstructs one durable result rather than duplicating progress. For remote workspace selection, test with forwarding headers and a server-only path. The event-bus source reports a seeded browser compaction test, but also discloses environment-dependent full-suite failures and that a full Docker image was not built.
Caveat
The webhook and remote-picker proposals were open; the event-bus PR was closed. This is source-inspected direction, not proof that all three behaviors are available in the latest tag. Contributor tests are attributed and were not rerun here.
The webhook and remote-picker proposals were open; the event-bus PR was closed. This is source-inspected direction, not proof that all three behaviors are available in the latest tag. Contributor tests are attributed and were not rerun here.