* feat(control-ui): stream live draft previews in the typing indicator
Multi-identity sessions now show what a teammate is typing, not just that
they are typing: the composer's per-keystroke session.typing sends carry a
bounded tail of the draft (optional preview field, 400 code points max),
the gateway throttle re-emits on changed payloads at 250ms (boolean-only
stays at 1s, trailing edge keeps the latest draft), and the transcript
renders a per-actor bubble with the live text plus a blinking caret.
Actors without preview data keep the three-dot bubble.
Previews are ephemeral presence: never persisted, never part of the
session transcript or model context, excluded from aria-live regions, and
gated by the existing >=2-live-viewers, sharing-role, and incognito
checks. No new config surface.
* chore(protocol): regenerate Swift gateway models for typing preview
* fix(gateway): aggregate typing previews across same-actor connections
A boolean-only session.typing update from a second connection of the same
actor (another tab or device) erased their live draft preview, because
typing liveness aggregated per actor while the broadcast preview came only
from the latest request. Preview aggregation now lives with the connection
aggregation owner: updateTypingConnections tracks per-connection previews
and returns the newest non-empty preview among live connections, so the
broadcast keeps the active draft until its connection stops or expires.
Regression fails pre-fix (event lost its preview field).
`main` is red: `check-lint-core-5` fails with
ui/src/pages/cron/view.test.ts
1124:4 error File has too many lines (1004). eslint(max-lines)
The file has been growing for a while (1104 lines at fa75cdd01c, 1116 at
2acfc47b7f) and crossed the 1000 code-line cap at a4b3f63a87 (#126945). Every
PR opened since inherits the failure, so this is not any one PR's fault to fix
in passing -- it blocks the merge gate for everyone.
Repo policy forbids a `max-lines` suppression, so the file is split along the
seam it already had: three top-level describes, one of which was two thirds of
the file. `cron view editor` moves to `view.editor.test.ts`; `cron view list
pane` and `cron view selects` stay in `view.test.ts`. The four DOM helpers the
blocks shared move into the existing `view.test-support.ts` sibling rather than
being duplicated, and each file imports only what it uses.
No test content changed: 42 tests before, 42 after, same 41 `it(` declarations.
Sizes drop to 373 / 721 / 143 lines, all well under the cap.
* fix(cron): reject blank/invalid --webhook before delivery.mode flip
Presence-only typeof checks treated empty or non-http --webhook as a
delivery edit, forging mode=webhook with no URL and clearing the prior
chat destination on merge. Validate with normalizeHttpWebhookUrl first.
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* test(cron): cover webhook validation boundaries
Amp-Thread-ID: https://ampcode.com/threads/T-01a0220d-eaa0-76b4-adb9-68841f015b75
---------
Co-authored-by: zyw02 <zyw02@users.noreply.github.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
Co-authored-by: Amp <amp@ampcode.com>
* fix(cron): reject blank --model/--thinking on cron edit
Empty Commander values skipped the clear-* mutex after normalize, so
--model '' --clear-model still cleared the override. Align with fallbacks
and delivery clear presence checks.
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* test(cron): align empty model/thinking edit expectation with blank reject
The legacy cron-cli suite still expected blank --model/--thinking to be omitted; that contradicts the fail-closed blank validation and broke CI.
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(cron): mutex blank --model/--thinking with matching clear flags
Standalone blank overrides stay omitted. Flag presence now conflicts with
--clear-model/--clear-thinking instead of silently applying the clear.
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* test(cron): focus blank clear mutex coverage
Amp-Thread-ID: https://ampcode.com/threads/T-01a0220d-eaa0-76b4-adb9-68841f015b75
---------
Co-authored-by: zyw02 <zyw02@users.noreply.github.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
Co-authored-by: Amp <amp@ampcode.com>
`openclaw skills install <slug>` and `skills verify <slug>` both answered a
ClawHub 404 with:
Skill "nonexistent-skill-xyz" not found. Run `openclaw skills list` to see available skills.
ClawHub is saying the slug is not in the registry. `skills list` lists the skills
already installed locally, so it cannot resolve a registry miss -- the operator
is sent to look at what they already have when they were trying to acquire
something new. `skills search` exists for exactly this and is one line away in
`skills --help`.
The sibling gets this right, which is what makes it a defect rather than a
preference: `plugins install <unknown>` answers with "Run `openclaw plugins
list` to see installed plugins, or `openclaw plugins search <name>` to look for
installable plugins."
The 404 branch now names ClawHub as the source of the miss and suggests
`skills search <slug>`. It also routes through `formatCliCommand` like the rest
of the file's sibling messages, so the suggestion stays correct under `--profile`
or `--container`; the hardcoded string did not.
The local-lookup message in `skills-cli.format.ts` is unchanged: there
`skills list` is the right answer, because that path is looking for a skill the
operator should already have.
Production +4/-1.
Doctor is the designated repair owner and nearly every CLI failure footer in this
product ends with `Try: openclaw doctor`. With a corrupt shared state database it
produced this, and nothing else:
┌ OpenClaw doctor
database disk image is malformed
No path. No indication of which database. No next step. `doctor --fix` printed
the identical two lines and repaired nothing, `OPENCLAW_DEBUG=1` added nothing,
and the standard `Reason:`/`Debug:`/`Try:` envelope never appeared. The operator
was in a closed loop: every command told them to run doctor, and doctor told
them a SQLite string with no object attached to it.
Corrupt the agent database instead and doctor already does the right thing --
names the file, names the reason, warns visibly, completes the full run, exits 0.
Same corruption class, two databases, opposite treatment.
The mechanism: `assertDoctorDatabaseSchemasCompatible` read
`preflightOpenClawDatabaseSchemas` and inspected only `incompatible`, silently
discarding `indeterminate`, which is exactly where an unreadable shared database
is recorded with its path and reason already populated. Doctor then proceeded and
died deeper with the context stripped, at
`src/infra/sqlite-readonly-location.ts:428` by way of state ownership inspection
and the config preflight.
Doctor now consumes that dropped signal and stops with a diagnosis that names the
file, the reason, what it deliberately did not do, and how to recover. It stops
rather than continuing like the agent-database path because shared state owns
write admission and holds the persisted plugin index the health context is built
from; disabling migrations still fails on that index, so continuing would mean a
bespoke degraded doctor. It does not recreate the database: that file holds auth
profiles among other things, so silent rebuild is data loss.
Also fixes an adjacent leak found in the same investigation: `io.load.ts` passed
a raw `Error` to the logger, so `doctor --session-sqlite inspect` printed a stack
trace with absolute `dist/*.js` frames without `OPENCLAW_DEBUG=1`, contradicting
the CLI's own debug-gating convention. It now logs formatted message text.
`doctor --lint` exiting 1 while bare `doctor --json` exits 0 was investigated and
left alone: commit 6e5bf3ec55 established that advisory JSON exit behavior
deliberately, and register.maintenance.test.ts covers it.
Production +11/-1.
Preserve honest blocked proof outcomes and publish visible stop-reports without marking them passed. Serialize burst runs through the authoritative Telegram-user lease while reserving time for proof and cleanup.
Two defects in one command, both on the path a brand-new operator is on
immediately after `openclaw onboard`.
`channels status` never mentioned channels when none were configured. With the
gateway up it printed `Gateway reachable.` and a tip about `status --deep`;
without it, two blank lines where the channel list belongs. The operator asked
for the status of their channels and got gateway reachability. Its siblings
already handle this -- `channels list` prints `- no configured chat channels
(run \`openclaw channels list --all\` to see installable channels)` and
`openclaw status` prints `No channels configured` -- so `channels status` was
the lone holdout. Both renderers now emit that same line, moved to a shared
constant so the three surfaces cannot drift apart again.
The second is worse because it sends the operator somewhere wrong. The fallback
computed `gatewayAuthUnavailable = expectedError || isGatewaySecretRefUnavailableError(err)`,
and `isExpectedCliError` returns true for `isGatewayTransportError` -- a plain
ECONNREFUSED. So a gateway that simply was not running reported `Gateway auth
unavailable; showing config-only status.`, contradicting the `Gateway not
reachable at ws://... (ECONNREFUSED)` line printed three lines above it. Someone
who runs `channels status` before starting the gateway went hunting for a token
problem that did not exist. The flag now consults only the two genuinely
auth-related predicates; `expectedError` keeps its separate job of selecting the
canonical CLI failure output.
`isGatewayCredentialsCliError` becomes exported for that check. The JSON shape is
unchanged; only the truth of `gatewayAuthUnavailable` changes, and no test or
documented contract depended on transport errors setting it.
Production +27/-9.
`skills` (#126954) turned out to be one instance of a class. Two more surfaces
accepted an agent id that names nothing, and one of them wrote it to disk:
- `sandbox explain --agent nope-agent` exited 0 and printed a complete policy
report, including `Elevated: enabled: true` and a workspace root that does
not exist, for an agent `openclaw agents list` does not know.
- `approvals allowlist add "<pattern>" --agent nope-agent` exited 0, printed
`Writing local approvals.`, and persisted the entry under a key nothing will
ever read. The operator believes they approved an exec pattern; nothing was
approved. This is the severe one: a false record of an approval.
Sweeping `option("--agent"` across the CLI found the rest. Each hit was
classified as a selector (names the thing operated on, must validate) or a
filter (narrows a list, may legitimately return empty). Selectors now route the
explicit value through `resolveConfiguredAgentId`, the helper that already backs
`models`, `memory`, `sessions list`, `hooks`, and every capability surface:
`channels resolve`, `sessions export-trajectory`, `sessions archive/delete`,
`backup enable`, `backup git create`, `backup sqlite create`. Blank-only guards
close the empty-shell-variable hole in `hooks`, `sessions` list/cleanup/tail/
compact, `migrate`, and agent turns.
Filters are deliberately unchanged: `audit`, `usage-cost`, agent bindings,
`backup verify/restore`, and `sandbox recreate` all match existing records and
correctly report no matches. Cron is gateway-owned and already rejects an
unavailable agent server-side; it is untouched.
`sessions archive/delete` was not silent -- it failed with `Session not found.
Run openclaw sessions list --agent ghost --json to choose a valid key.` But that
suggested command itself exits 1 with `Unknown agent id "ghost"`, so the
remediation handed to the operator could not run. Validating locally, exactly as
`sessions list` already does, keeps the hint runnable without adding a roster
round-trip to the gateway.
Production +140/-38.
Control UI now preserves active-run commentary and tool progress when a follow-up steers the same run, while fresh sends still clear stale projection state.
Fixes#126938.
Reviewed-by: @shakkernerd
`openclaw skills check --agent nope-agent` exited 0 and printed a full report
headed "Agent: nope-agent" with 53 skills / 44 eligible, while the install's only
real agent reported 57 / 48. It did not fall back to the default -- it fabricated
an agent and produced confident, different numbers for it. `skills list` behaved
the same way.
Every sibling --agent surface already rejects an unknown id: `models auth list`,
`models list`, `models status`, `memory status`, and `sessions list` all exit 1
with "Unknown agent id". Skills was the only holdout, and the canonical helper
for it already exists -- `resolveConfiguredAgentId`, added for this exact class
when `memory --agent` had the same hole.
`resolveSkillsWorkspace` took the explicit --agent value verbatim while both the
workspace-inferred and default paths were validated. Route the explicit value
through `resolveConfiguredAgentId` so the message and behavior match the
siblings, including the profile-aware hint, and reject a blank --agent the way
memory does. Workspace inference and default resolution are unchanged.
Production +9 LOC.
With an external CLI credential discoverable, `models status` printed
"Auth store: <state>/agents/main/agent/openclaw-agent.sqlite" while
`models auth list` printed "<state>/state/openclaw.sqlite" -- two commands, one
install, different answers, and the agent database held no auth rows at all.
`resolveAuthStorePathForDisplay` chose between the agent-local file and the
shared owner with `hasLocalAuthProfileStoreSource`, which returns true for a
runtime snapshot. External-CLI discovery populates an agent-scoped runtime
snapshot, so `models status` -- which performs that discovery -- concluded the
agent owned a local store file. Those credentials live in the external tool's own
files, never in the agent database. Pointing HOME at an empty dir removes the
discovery and both commands already agreed, which isolates the trigger.
The displayed value is a file path, and only persisted state lives in a file, so
the decision now uses the persisted store probe. A genuinely local persisted
store still wins, including without an ownership record.
Peter Steinberger