Live-testing #126377 in a real explicit fleet surfaced an inaccuracy that PR
introduced. It dropped 'Other agent-scoped methods do not use this setting as a
general default', which is still true: only models.list, models.authStatus,
skills.status, and doctor.memory.status opt in, while the generic Gateway
resolver in agent-id-shared.ts deliberately does not.
Verified against a live gateway and CLI on a three-agent explicit fleet with
systemAgent.agentId set: 'openclaw models list', 'openclaw sessions', stored
session lookup, and TUI startup all still require an explicit agent. Name those
surfaces so operators know where the owner does and does not apply.
* Move raw transcript from system to user prompt to protect provenance.
* Type fix.
* fix(voice-call): harden transcript context handling
* fix(voice-call): initialize inbound Twilio control state
* test(voice-call): align runtime coordinator fixture
---------
Co-authored-by: joshavant <830519+joshavant@users.noreply.github.com>
* fix(cli): route bare startup on configured inference, not a default agent
Bare `openclaw` resolved a single "default" agent to decide whether inference
was configured. On an explicit multi-agent roster (agents.ownership="explicit"
with 2+ entries) that resolution has no answer, so startup threw
AgentSelectionRequiredError instead of launching the TUI or onboarding.
The branch only needs to know whether inference is configured at all, so it now
asks exactly that across the roster and hands off to the TUI, which already
owns agent selection and resolves by workspace path first. Routing ambiguous
rosters to onboarding instead would have dropped a working multi-agent install
back into the setup wizard.
* fix(cli): honor the configured system agent for model read commands
`openclaw models status`, `models list`, `models auth list`, and
`models auth-order get` resolved a deprecated "default" agent when --agent was
omitted, so they threw AgentSelectionRequiredError on an explicit multi-agent
roster. schema.help.core.ts already documents agents.defaults.systemAgent.agentId
as the owner for these unscoped reads, and the Gateway twins
(models.ts, models-auth-status.ts) already honored it; only the local CLI paths
did not.
resolveModelsTargetAgent now takes a closed read/mutation mode. Reads resolve
explicit --agent, then the configured system agent, then a sole agent.
Credential mutations still require an explicit owner rather than guessing which
agent to write into, and say so with a flag that exists on those commands.
The deprecated resolver is gone from this owner. Help text for the two commands
whose default changed now names the system agent.
* fix(outbound): resolve ambient delivery owner through the system-agent chain
Agent-less outbound channel bootstrap resolved its owner via the deprecated
throwing resolver, so multi-agent explicit-ownership configs with only
agents.defaults.systemAgent.agentId set threw AgentSelectionRequiredError from
inside gateway delivery recovery, aborting the whole drain ("Delivery recovery
failed") for every queued entry.
Bootstrap now follows the same ambient owner chain heartbeats and cron use
(legacy default, then systemAgent, then sole agent), consolidated into one
canonical tryResolveAmbientOwnerAgentId in agent-scope-config; the duplicated
chain in cron/agent-id.ts is deleted and heartbeat resolution reuses the
helper. Truly ownerless fleets no longer throw either: bootstrap proceeds with
global-scope plugin discovery only, never selecting an agent workspace, so
per-entry delivery outcomes stay recorded instead of one entry starving the
recovery loop.
Regression tests fail pre-fix: agent-less bootstrap routes through the
configured system-agent owner, and ownerless fleets bootstrap without
throwing.
* refactor(agents): route ambient owner resolution through one canonical chain
The idiom `tryResolveLegacyCompatibilityAgentId(cfg) ?? resolveDefaultAgentId(cfg)`
was copied across nine ambient surfaces. It reads like a fallback but is not: when
the first call returns undefined, resolveDefaultAgentId reduces to resolveSoleAgentId
and throws, so the second leg only ever throws — and neither leg consults
agents.defaults.systemAgent.agentId. Every one of those surfaces raised
AgentSelectionRequiredError in explicit fleets that own ambient work through a
system agent.
Promote the chain to one owner in agent-scope-config: tryResolveAmbientOwnerAgentId
(undefined when ownerless) and resolveAmbientOwnerAgentId (throws with the caller's
existing selection context). The throwing variant is a drop-in for every former
composite: identical message when a fleet has no owner, but the system-agent leg
now resolves.
Converted: resolveDefaultAgentDir (the shared producer behind auth, model catalog,
doctor, wizard, and Plugin SDK helpers), config identity-avatar validation, prepared
model catalog and registry, session reset, Talk target, main-session routing and its
routing-contract fingerprint, session store targets, hooks CLI, plugin LLM
completion, and first-run onboarding.
resolveDefaultAgentId keeps backing explicit-selection surfaces where 'pass --agent'
is the right answer; its deprecation note now sends ambient callers to the new
helper.
* fix(sessions,hooks): keep agent-narrowing surfaces on explicit selection
CI caught the over-reach: session-store listing and hooks status reporting are
deliberately explicit-selection surfaces, not ambient system work. Both narrow
output to one agent, so adopting agents.defaults.systemAgent.agentId would hide
the other agents' sessions/hooks instead of failing with the escape hatches the
operator needs. sessions.default-agent-store.test.ts pins that contract by
configuring a system agent and still expecting the --agent/--all-agents error.
Restore the prior behavior at both sites, spelled honestly as
tryResolveLegacyCompatibilityAgentId ?? resolveSoleAgentId — provably identical
to the old composite, since the composite's second leg could only ever throw —
with a comment recording why these two resist the ambient chain.
* test: declare the ambient owner binding in agent-scope mock factories
Explicit vi.mock factories enumerate exports, so production calling
resolveAmbientOwnerAgentId broke prepared-model-catalog, prepared-model-registry,
and channel-resolution with 'No "resolveAmbientOwnerAgentId" export is defined on
the ... mock'. Declare it in the four factories; channel-resolution now drives the
non-throwing variant the bootstrap actually calls.
Also restore session-store targets and hooks status to their exact previous code.
Both stay out of the ambient chain by design, so the smallest correct diff at an
out-of-scope site is none: they now differ from main only by the comment recording
why they resist it.
* fix(models): resolve the model-config workspace through the ambient owner
ClawSweeper P1: prepareModelsConfigContext resolved agentDir through
resolveDefaultAgentDir (ambient chain) but its workspace through
resolveDefaultAgentId (deprecated throwing chain), so explicit fleets owned by a
system agent still failed model preparation on the workspace lookup — a one-sided
fix inside a single function.
Both halves now resolve the same ambient owner.
* docs(agents): describe the widened ambient system-agent ownership
config-agents.md claimed 'Other agent-scoped methods do not use this setting as
a general default', which this branch makes false: systemAgent.agentId is now
the ambient owner for agent dir/workspace resolution, outbound bootstrap and
delivery recovery, main-session routing, Talk, and onboarding.
Record the widened set, the two surfaces that deliberately still demand explicit
selection (sessions, hooks), and delivery recovery's per-entry degradation.
* refactor(ui): share Control UI resource route contract
Gateway and Control UI now share browser-safe resource route grammar, while authorization and domain validation remain handler-owned.
* perf(ui): keep resource routes out of startup
Narrow browser-safe contract modules and the lazy authenticated avatar loader keep route/cache code out of the startup chunk while the stable Gateway barrel remains compatible.
* fix(ui): render one assistant reply when history and the terminal event race
A finished run's reply reached the Control UI twice: the durable transcript
row and the pane's own terminal projection shared no identity, so the
projection reducer kept both and the transcript collapsed them behind the
"x2" duplicate badge. The gateway's chat final event carries no message id,
and a durable assistant row carries no run id, so the reducer's same-run
promotion could never match them. A WeakMap side channel hid the duplicate
only when history happened to be applied before the terminal event arrived,
which made the badge look intermittent.
The pane now admits the durable assistant row of the run it is finishing
through the reducer, attributed to that run, so the durable row adopts the
terminal projection in place; the reducer refuses to downgrade a row that
already carries a transcript id back to an id-less projection.
Splits the run-terminal bookkeeping tests into a sibling file to stay under
the max-lines ratchet.
* fix(ui): bind a late reply row to its run only when it carries that reply
The terminal tombstone outlives its run by design, so attributing every
unowned assistant row to it could stamp a delayed older row with a newer
run's id; the reducer then matched that row to the newer run's terminal
projection and replaced the answer the user should see. The tombstone now
claims only the row carrying the reply already projected for that run.
* fix(channels): separate routing from receipt identity
Routing identifiers no longer fabricate message delivery evidence; provider-canonical thread placement is preserved.
* fix(channels): preserve conflicting receipt threads
Keep aggregate thread placement absent when provider receipt parts disagree, even when a requested route thread is available.
* fix(media): stop canonicalizeBase64 allocating one cons-string node per char
Per-character append built a rope of ~25 bytes per input character, all
live until the final join — a 20 MB base64 attachment transiently needed
~700-900 MB of heap and OOM-crashed the gateway on POST /v1/responses.
Validate in the same single pass but collect contiguous non-whitespace
runs as slices; already-canonical input is returned unchanged with zero
allocations. Measured: 15 MiB attachment 659 MB -> 0 MB transient heap,
4.3 s -> 0.2 s.
* fix(media): bound canonicalizeBase64 cleanup memory by input length
Review found the run-slicing cleanup unbounded for adversarial input:
alternating data characters and whitespace retains one slice object per
run (measured 421 MB of heap for an 8 MiB payload shredded to one run
per character). Replace the run collection with a single output buffer
materialized on the first whitespace and filled in the same validating
pass: canonical input still returns unchanged with zero allocations, and
any whitespace shape now costs at most one buffer bounded by the input
length (measured 0 MB heap delta, 210 ms for the same shredded payload).
Adds the many-short-runs regression test the review asked for, guarding
both heapUsed and arrayBuffers.
* refactor(media): condense canonicalizeBase64 invariant comment
Review asked for the repository's 1-3-line invariant form: keep why the
buffer is lazy and bounded, drop the implementation-history narration.
* chore: retrigger CI (flaky gateway-server shard)
* test(media): update base64 memory comment
Punchcard-Session: frost-cedar-willow-ae
---------
Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
The model catalog abort test waited for pid-file existence, but the
catalog child's writeFileSync exposes an open-truncate window: the
test could read the file empty and fail on a NaN pid assertion
(CI run 32231699569, checks-node-changed-extensions-config-37).
Add a qa-lab-local process-wait test helper that waits for the
asserted state (a parseable pid) with generous 10s deadlines and
self-diagnosing timeout errors, and consolidate the two hand-rolled
helper copies in model-catalog.runtime.test.ts and
test-file-scenario-command-lifecycle.test.ts onto it. Also retire
the stale 1.7s abort-settle ceiling (calibrated against a removed
1.5s in-plugin kill grace) in favor of a 5s bound with the contract
documented.
normalizeCloudRepo hand-rolled an scp-form regex that also matches
scheme URLs, so ssh://git@host:22/owner/repo put the port in the
repository path (github.com/22/owner/repo). Operators with a ported ssh
remote silently lost their cloudWorkers.projectProfiles mapping: dispatch
fell back to no-mapping behavior with no visible outcome.
Delegate to parseGitUrl, the parser project memory scope already uses for
the same host/path identity derivation, which folds userinfo, ports, and
scp-vs-scheme forms and rejects traversal. Only the config-specific
lowercase folding stays local.
* fix(line): deliver a location LINE cannot render instead of dropping it
A location whose title or address is blank makes LINE reject the whole
request, so every delivery path filtered it out before sending. The reply
then arrived without the pin, and nothing told the user or the operator that
a part of the message had been removed: the coordinates the sender supplied
were discarded silently.
The location builder now answers with the values the sender wrote — the
non-blank label plus the coordinates — as a text message, so an unrenderable
pin degrades into something the chat can show instead of disappearing. Both
delivery paths inherit that from the single builder, and the three call sites
that used to skip a null result no longer have a branch to take.
Live validation against the Messaging API confirms the shape: the authored
location is rejected with "May not be empty" on messages[0].address, the same
rejection kills an entire batch that also carries valid text, and both
degraded forms validate cleanly.
* fix(line): bound the location fallback to LINE's text limit
Nothing caps the location labels at the schema, so a long title with a blank
address produced one raw text message past LINE's 5,000-character limit — the
provider rejected it and the location was lost exactly as silently as before.
The pin path already caps each label at 100 characters. Name that limit and
apply it in the fallback too, so both forms carry the same bound instead of
one of them re-deriving the provider's rules.
* test(line): merge the duplicate send.js imports
* fix(cli): resolve infer command owners via --agent and systemAgent fallback
Multi-agent rosters (agents.ownership=explicit) dead-ended every infer
runner command: resolveDefaultAgentId threw AgentSelectionRequiredError
telling callers to pass --agent, a flag none of the commands registered,
and agents.defaults.systemAgent.agentId was ignored.
Route model run, image generate/edit/describe/describe-many, video
generate, embedding create, and model auth logout through the existing
resolveCapabilityProviderAgentId chain (explicit --agent, then
agents.defaults.systemAgent.agentId, then the sole agent) with
per-command error surfaces, and register --agent on each command.
* docs(config): scope systemAgent infer fallback help to agent-owned commands
Vincent Koc