Nanobot puts a brake on goals that keep talking while waiting

HKUDS/nanobot PR #5257 is the inspected primary source: “fix(agent): bound sustained-goal continuation when the turn goes idle.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- HKUDS/nanobot PR #5257 was created 2026-08-05T12:29:39Z and was open at inspection; its title is “fix(agent): bound sustained-goal continuation when the turn goes idle.” - HKUDS/nanobot issue #5256 was created 2026-08-05T12:06:43Z and was open at inspection; its title is “Bug: /goal message produces dozens of repeated replies when waiting for user's answer.” - HKUDS/nanobot PR #5255 was created 2026-08-05T08:33:58Z and was open at inspection; its title is “Draft: truthful API service status for externally-managed servers + `nanobot api status`.” - The repository reported 46686 stars, 774 open issues, default branch main, and last push 2026-08-05T12:04:32Z. - The latest tagged-release baseline checked was v0.3.0 published 2026-07-25T08:08:47Z.

What changed

HKUDS/nanobot PR #5257 reports: Summary Goal continuation deliberately bypassed _MAX_INJECTION_CYCLES, so a session with an active goal had no bound on it: every plain-text final response injected another "keep working or complete the goal" nudge. A model waiting on the user could only rephrase the same answer, burning the whole iteration budget on one message. Count continuations that produce no tool call against _MAX_GOAL_IDLE_CONTINUES and clear the streak on any tool execution. Real user injections are drained before the guard is consulted, so user input is never suppressed. The goal stays active because it is waiting, not done. Fix Fixes #5256 Validation On a real channel: repeated replies sent to user is bounded by _MAX_GOAL_IDLE_CONTINUES and goal is still set as "active" at beginning of next turn, so model chose to update_goal along with user's info later.

HKUDS/nanobot issue #5256 reports: Bug Description Summary A single /goal message produced dozens of near-identical replies, all sent while the agent was waiting for an answer from the user. It ended only when the user intervened, or when the model finally recognised as a system loop and marked the goal cancel. The trigger is a goal in active state plus a final response that waits on the user, which is typically a question back to them. nanobot then re-prompts the model to "continue working toward the objective and loops. The model has no substantial work to do (it needs the answer) and cannot mark the goal complete (the objective is unmet), so it rephrases the same message. Every rephrase is a visible reply. That re-prompt is exempt from the brake that limits ordinary mid-turn injections: _MAX_INJECTION_CYCLES is only advanced for real user injections, so the goal continuation never advances it (nanobot/agent/runner.py, _try_drain_injections). What is

HKUDS/nanobot PR #5255 reports: Summary This draft proposes two related changes so the WebUI's API server section tells the truth about nanobot serve instances that the gateway did not start: 1. The panel currently reports the API as **Off** whenever it was not started by the gateway itself — even when a nanobot serve process is actively answering on the configured port (e.g. launched by systemd, docker, tmux, or any external supervisor). It also offers a Start button that would spawn a second server into the occupied port (EADDRINUSE). 2. There is no CLI surface that reports the API server's status: nanobot status covers config/provider readiness only, and nanobot gateway status covers the gateway process. The WebUI panel is the *only* nanobot-native status surface for the API — and it is wrong for externally-managed instances. The proposal: report the API as running when a nanobot API provably answers on the configured port, mark it

Why it matters

A goal that cannot progress should wait, not consume the remaining iteration budget while rewriting the same question into history. Process status has the same distinction: reachable is not the same as owned. The operator test is whether persisted state, execution authority and the visible outcome describe the same event after retries, restarts or delegation.

Current

The primary record was open when captured on 2026-08-06. The release baseline was v0.3.0 published 2026-07-25T08:08:47Z. Repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts row were checked. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/HKUDS/nanobot/pull/5257. Supporting records are https://github.com/HKUDS/nanobot/issues/5256 and https://github.com/HKUDS/nanobot/pull/5255. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Bound no-tool goal continuations without clearing the goal, drain real user input first, and refuse start/stop controls for an externally managed API. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.