Fifty cases across core, cli, browser-use, sdk-typescript,
test-failure-explorer and scripts/tests force a failure with chmod and
skip whenever uid is 0. ci.yml runs unit tests as root on the ECS pool,
but drops CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH first, so permission
bits bind there and these cases could run; the uid check skips them all
on that lane anyway.
Gate them on whether a mode-000 directory refuses this process, as #14162,
#14271 and #14283 do for the rest:
- core (22 cases in 14 files) and cli (1) use their own helper.
- browser-use, sdk-typescript and test-failure-explorer import nothing
from another package, so each gets a copy of the helper; browser-use,
with six cases, also gets its tests, as core did in #14283.
- scripts/tests (19 cases in 7 files) imports the cli helper, as other
scripts tests do.
Three core cases returned early as root instead of skipping, so they
reported a pass without asserting anything; they now skip there. The
workflow-extension case left its unreadable directory empty, so it passed
whether or not the directory was refused; it now holds a workflow that
would show up if it were read.
package-scripts pins every copy of the helper, and the cli, core and
browser-use copies of its tests, byte-identical, so a fix to one cannot
leave the others behind.
Left on the uid check: pathReader's case, whose permissions come from
mock-fs, which lets uid 0 through whatever the mode; the session writer
lease's chown case, which needs root; and the release workflow's wipe
test, which does not depend on permission bits.
* feat(memory): bundle Mem0 with the main CLI
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* feat(memory): support settings-defined Mem0 credentials
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* fix(memory): preserve bundled Mem0 trust and configuration boundaries
Ignore repository-scoped MCP conflicts, require the genuine bundled runtime for confirmation hooks, and use native artifact paths in packaging assertions. Improve field diagnostics and document existing precedence, scope, and verification limits.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* fix(mem0): close three review Criticals on the bundled Mem0 binding
R1-1 (scripts/tests/package-assets.test.js): the two new multi-segment
`missingArtifact` entries are compared against a message built with
`path.join`, so `mem0/main.js` never matches the `\`-joined Windows path.
Normalise the separator in the assertion; single-segment entries and POSIX
behaviour are unchanged.
R1-2 (packages/cli/src/config/config.ts): the mem0/external-context conflict
guard read the merged all-scopes map, so a `external-context` entry that a
trusted repository contributes through its own `.qwen/settings.json`
(`scope: 'workspace'`) aborted `loadCliConfig` for every operator who
configured `memory.mem0` — before `assembleMcpServers` applied the approval
gate that would have held that server pending anyway. Limit the settings leg
to operator scopes via `isGatedMcpScope`; a gated-scope entry is now
overridden by the built-in binding (topTierMcpServers spreads last), exactly
as a `.mcp.json` entry of the same name always has been, matching the design
doc this PR adds.
R1-28 (packages/cli/src/config/mem0-settings.ts): `bundledMem0Hooks`
identified the bundled server by duck-typing an env-var name plus
`includeTools`, so a repository-authored `external-context` entry reaching
the `/hooks` reload path through `getMcpServers()` was filed under
`systemHooks` — the one hook source folder trust does not gate — rendered as
`[System]` configuration and pointed at a different script than the one the
MCP approval dialog showed. Require identity instead: every file-sourced
entry carries a provenance `scope`, the bundled one never does.
Tests: workspace-scoped override + operator-scoped conflict still throws
(config.test.ts), three scoped-entry rejection rows + an unscoped positive
control (mem0-settings.test.ts), and a control/negative pair on the real
reload path (hooksCommand.test.ts). Each fix was mutation-proved red.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmultfgjtdh
* test(mem0): pin the spawn interpreter, timeout slack and both bound copies
R1-23: nothing in the repo observed `server.command` or `server.timeout`, and
the `memory.mem0.timeoutMs` bounds are declared independently in
mem0-settings.ts (zod, the runtime contract) and settingsSchema.ts (the
settings-dialog copy). Replacing `command: process.execPath` with `'node'`, or
dropping the `+ 5000` slack, left every suite green — a packaged or
GUI-launched install routinely has no `node` on PATH, and the same value gates
`bundledMem0Hooks` and is interpolated as the hook interpreter.
Adds, in mem0-settings.test.ts: `command === process.execPath`,
`config.timeoutMs === 5000` / `server.timeout === 10_000` for the default, an
accept row at the documented ceiling asserting `35_000`, and reject rows for
`0` / `30001` / `1.5`. Adds, in settingsSchema.test.ts, the bound test mirroring
the existing `tools.webSearch.timeoutMs` precedent so the JSON-schema copy is
pinned to the same documented numbers (docs/users/features/mem0.md: "defaults to
5000, between 1 and 30000").
Mutation-proved individually: `process.execPath` -> `'node'` red, `+ 5000`
removed red, `maximum: 30000` -> `60000` red; intact tree green (27 + 61).
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmultfgjtdh
* fix(mem0): restore PolarDB direct-import text on retrieval
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* test(mem0): use the real bundled binding in hook reload control
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* fix(memory): Preserve Mem0 operator and legacy preset semantics
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* test(memory): Pin Windows Mem0 package artifact errors
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* fix(memory): Retain Mem0 safeguards across reloads
---------
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* feat(external-context): Support open-source Mem0 providers
Add a mem0 provider type to the external-context integration that speaks
the open-source Mem0 REST API (POST /v2/memories/search for on-demand
recall, POST /v1/memories with infer:false for exact direct-import
writes), so self-hosted mem0 servers and managed OSS-protocol services
such as Aliyun PolarDB Mem0 can serve as the external context corpus.
The tenant identity (user_id, optional app_id) is fixed in the
administrator-managed configuration and is never supplied by the model.
A new allowInsecureHttp opt-in permits plain-HTTP endpoints such as
PolarDB Mem0 while credentials-in-URL remain rejected.
Refs #9951
* test(external-context): Cover the open-source Mem0 example config
Assert the exact example structure and that it loads through loadConfig
once the endpoint and user placeholders are substituted, so the shipped
sample cannot drift from the provider schema.
* refactor(external-context): Address review on the mem0 provider
Enforce the OSS baseUrl policy only in the adapter constructor, matching
the sibling providers, and have the rejection message point at the
allowInsecureHttp opt-in. Extract the shared write-rejection classifier
used by both Mem0 adapters, pin localhost and IPv6 loopback acceptance,
cover non-HTTP write failures mapping to unknown, clean up the example
test's temp directory, and correct the README rollout guarantees and the
OSS write-enablement guidance.
* fix(external-context): Ship the mem0 example with HTTPS defaults
The example pre-enabled allowInsecureHttp, inverting the README guidance
it is cited by. Default to an HTTPS baseUrl without the flag; the hinted
validation error and the README paragraph lead plain-HTTP whitelist
deployments to the explicit opt-in.
* test(external-context): prove shipped mem0 example constructs a provider
* refactor(external-context): address mem0 review round — merge duplicate arms, gate HTTP hint, fix README wording
* fix(external-context): Scope OSS mem0 by agent_id instead of app_id
The open-source mem0 v1.0.1 REST protocol (implemented by Aliyun PolarDB
Mem0) scopes memories by user_id / agent_id / run_id; app_id is a
hosted-platform-only field these endpoints do not accept. Rename the
optional mem0 provider field to agentId, send it as agent_id, and place it
top-level in the v2 search request (filters carry user_id) to match the
protocol.
Verified live against a PolarDB Mem0 instance: add and search accept
agent_id, infer:false is honored for direct import, and the MCP chain works
end to end.
* fix(external-context): Scope Mem0 provider to PolarDB
* feat(external-context): add versioned Mem0 presets
Replace the protocol-specific draft provider with a generic Mem0 provider backed by reviewed, immutable presets for Mem0 Platform, stock Mem0 REST, and PolarDB.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* fix(external-context): survive an unverified Mem0 deployment build
The endpoint is operator-supplied and its build is not guaranteed - these
services are self-hosted or vendor-packaged, and the stock Mem0 REST server
carries no API version in its paths at all. A preset is therefore a claim
about what is deployed, and it can be wrong. Nothing here probes or falls
back; instead a mismatch is kept from passing silently.
Send session identity at both the request root and under `filters` for the
Mem0 server preset. `_build_filters_and_metadata` seeds the effective filters
from `filters` and then overwrites each identity key with the root value, so
one request resolves to a byte-equal scope on builds that read either
position. A filters-only search is rejected outright by builds predating that
move, which surfaced as a 500 rather than as an unscoped search.
Claim `stored` for a direct import only when the echoed `memory` matches the
submitted text and the event is not a delete. `infer: false` is what makes the
stored memory the exact text approved at the confirmation Hook, but a build
whose request model predates the field drops it silently, runs fact
extraction, and returns a rewritten memory with a valid identifier - reported
until now as `stored`.
Write provider failures to stderr with the HTTP status, which separates a
contract mismatch from an outage. The model-facing error stays opaque, and no
provider response body is ever written.
Rename the preset to `mem0-server-rest-2026-08`: "OSS" names an object storage
service in some of the clouds these deployments run in, and the preset list it
sits in already names one of those clouds.
Report which scope key and which basePath rule a configuration broke, narrow
the preset unions to the members a shipped preset uses, and cover the write
result classes, basePath rules, both scope rules in isolation, the identifier
bound, the direct-import basePath join, the Platform V3 preset write request,
and the mem0 arm of auto-recall credential scrubbing.
* feat(external-context): add a read-only Mem0 preset probe
Every other field of a `mem0` block is a fact the administrator already holds.
`preset` is not: it is a claim about which wire contract the deployment
implements, and these services are self-hosted or vendor-packaged, so the
answer is not visible from the configuration side. The configuration made that
claim mandatory without offering any way to check it.
The probe runs a candidate preset through the real adapter against the real
endpoint, so a preset that reaches the service but whose items the parser
discards is reported as the mismatch it is. It also reads the declared search
schema when one is served, and compares scope placements so a preset can be
moved to `body-and-filters` on evidence rather than on assumption.
An empty corpus is reported as inconclusive rather than as a pass: three
equally empty result sets look like agreement and are not.
Read-only. It issues search requests and one `GET /openapi.json`, never
writes, and never renders the credential.
* refactor(external-context): drop the vendor prefix from the PolarDB preset
PolarDB Mem0 is offered by more than one cloud, so an identifier scoped to one
of them reads as inapplicable to an operator running the same contract
elsewhere - the preset names a wire contract, not a vendor. The mapping's
verification evidence came from an Aliyun deployment, which the design doc now
says explicitly rather than encoding in the identifier.
Record who controls the build behind each preset, and probe placements only
where that is the operator. A vendor-operated service has one published
contract and no version skew to hedge against, so reporting that a different
request shape also works would invite a deviation with a cost and no benefit.
A skipped comparison no longer stands in for a working preset: when the
baseline search fails, the verdict is the mismatch, not "see the baseline".
* fix(external-context): restore bounded Mem0 contracts
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* docs(external-context): ship a PolarDB example that loads as it is shipped
The console hands out a plain-HTTP address and port, while the shipped example
carries an `https://` origin with no port - the shape the endpoint should have,
not the shape it arrives in. Pasting the console address into that example
fails the URL policy, and nothing tells the operator which of the legitimate
resolutions their deployment wants.
Add a loopback example instead of loosening the policy. An `ssh -L` relay
carries the credential and the memories, loopback HTTP loads with no opt-in, and
only the user id has to be substituted, so the path from a new instance to a
working search is one relay command and one copied file. The HTTPS example is
unchanged: pre-enabling the opt-in in a shipped file would invert the posture
the surrounding section asks operators to keep.
The loopback example omits `agentId`, which the preset sends at the request
root - a placement no PolarDB document confirms, and an optional field is not
worth staking a first connection on.
* docs(external-context): clarify PolarDB setup
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
---------
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* fix(live): restore Windows filesystem compatibility
* fix(ci): restore Windows test baseline
* fix(ci): keep release-age excludes internal and re-arm two witnesses
- pnpm-workspace.yaml: drop '@tybys/wasm-util@0.10.4' from
minimumReleaseAgeExclude. scripts/tests/package-scripts.test.js pins
that list to internal, version-independent entries. The exclusion is
also inert: minimumReleaseAge is not configured anywhere in the repo,
and pnpm-lock.yaml records `overrides` but not minimumReleaseAgeExclude
-- so the '@tybys/wasm-util': '0.10.4' override stays, because dropping
it would desync the lockfile and fail --frozen-lockfile.
- web-shell-brand.test.ts: build the swapped-file fake as BigIntStats.
Production compares bigint fields with a bare `!==`, so a number-backed
fake tripped `dev` first and the perturbed inode was never reached;
removing the perturbation now turns the test red again.
- run-qwen-serve.test.ts: '0' is unresolvable on Windows (getaddrinfo
ENOTFOUND 0), so the wildcard case keeps '0.0.0.0' and witnesses the
socket rather than a spelling: the operator typed port 0, so the report
must carry the ephemeral port the listener actually got. Spelling
normalisation stays pinned platform-independently in
remote-quickstart.test.ts.
- artifact-snapshots.ts: revert the readdir hoist to main. It is
behaviourally inert (the catch rethrows ENOENT on the operationId path
either way), has no test and no Windows link.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmu07e78o2w
* fix(ci): restore the load-bearing release-age exclude, keep the witness fixes
The previous commit dropped '@tybys/wasm-util@0.10.4' from
minimumReleaseAgeExclude to satisfy scripts/tests/package-scripts.test.js:390,
on the reasoning that the entry was inert because minimumReleaseAge is not
configured in this repo. That reasoning was wrong and CI measured it: the gate
is enforced by pnpm itself, not by repo config, so removing the exclude failed
'Install frozen pnpm worktree dependencies' on all three platforms with
Lockfile failed supply-chain policy check (1975 entries)
@tybys/wasm-util@0.10.4 was published at 2026-09-13T08:00:13.464Z,
within the minimumReleaseAge cutoff (2026-09-12T20:03:50.286Z)
(run 34779568628; Install was green at 6099768ffb, which carries the entry).
Restoring the line makes pnpm-workspace.yaml byte-identical to that head again.
The three other changes from that commit are kept, since they are independent
of the exclude and were green in run 34779568625 (Test 18m58s, Lint & Static
12m36s, Integration no-AK 7m8s): the web-shell-brand.test.ts BigIntStats fake
that re-arms the inode witness, the run-qwen-serve.test.ts socket witness
replacing the tautological '0.0.0.0' assertion, and the artifact-snapshots.ts
revert to main.
This leaves the package-scripts.test.js assertion red exactly as it was before
this round. That is now a measured conflict rather than an open question: the
repo test pins the exclude list to internal, version-independent entries, while
pnpm needs a version-pinned exemption for a package published the same day.
Resolving it means either dropping the '@tybys/wasm-util': '0.10.4' override and
regenerating both lockfiles so an older, age-compliant version resolves, or
relaxing the invariant to admit external version-pinned excludes. Both are
supply-chain policy calls for the author/maintainer, so neither is made here.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmu07e78o2w
* fix(ci): pin @tybys/wasm-util to the age-compliant 0.10.3 instead of exempting it
Test (ubuntu-latest, Node 22.x) failed at scripts/tests/package-scripts.test.js:390
(run 34781999892), which pins minimumReleaseAgeExclude to internal,
version-independent entries, while the previous head carried
'@tybys/wasm-util@0.10.4' there to satisfy pnpm's minimumReleaseAge gate. The two
looked mutually exclusive, but only because the pin chose the newest release.
@node-rs/jieba-wasm32-wasi pulls in @napi-rs/wasm-runtime@1.2.4, which accepts
^0.10.3, and 0.10.3 was published 2026-06-23 -- well outside the 24h window that
rejected 0.10.4 (published 2026-09-13T08:00:13Z). So the pnpm override now pins
0.10.3, the exclude entry is dropped, and both lockfiles follow: package-lock.json
must lock the same version or scripts/check-lockfile.js's "pnpm lockfile against
package-lock.json" agreement gate fails, which also reddens the two check-lockfile
fixture branches in package-scripts.test.js because they copy the real lockfiles.
The pin lives on the pnpm side only, mirroring how the typescript pins already
diverge; npm has no release-age gate, so no package.json override is added and the
nested @tailwindcss/oxide-wasm32-wasi copy of @tybys/wasm-util is left alone. Once
0.10.4 ages out of the window, a maintainer can drop the override from both sides if
nothing else needs the pin.
Verified locally: pnpm 11.24.0 `install --lockfile-only` reports "Lockfile passes
supply-chain policies (1975 entries)"; scripts/tests/package-scripts.test.js 49
passed / 1 skipped (was 3 failed); scripts/tests/check-lockfile.test.js 14 passed;
prettier --check clean.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-conflict/jmu0ce8qb32
* fix(ci): handle expected Windows socket reset
* fix(ci): make Windows regression tests portable
* fix(ci): make script tests portable on Windows
* test: re-arm four witnesses the review round found vacuous or over-gated
Each of these was measured, not argued; the mutation named in every case is
the one that used to leave the suite green.
- no-follow-open.test.ts: add the >2^53 identity case. Removing
`{ bigint: true }` from all four production stat call sites left 17/17
green, so the Windows-precision conversion this PR exists for was
unwitnessed. The fixture uses 2^60 offsets, where the double spacing is
256 and both ids collapse to one value; 2^53+1 / 2^53+2 do NOT collapse
(2^53+2 is exactly representable), so those constants cannot pin it.
Two-arm measured: intact 18/18 pass, mutated exactly 1 fails.
- web-shell-brand.test.ts: stat the planted regular file with
`{ bigint: true }`. Production compares BigIntStats with a bare `!==`, so
the number-backed fake tripped `dev` on a type mismatch alone and would
have refused the correct file too. Probed both arms: pre-fix
`typeof expectedStat.dev === 'number'` with the `dev` clause true,
post-fix both sides bigint with `dev` false and the refusal driven by a
real inode mismatch.
- conversation-workspace.test.ts: move the `inodeVerifiable` gate below the
two `toBe(identity)` assertions. They are inode-independent, so gating
them deleted a witness the Windows lane was green on. Modelled an
unverifiable-inode host: the test reports skipped, not failed, which is
only reachable once both assertions have passed.
- worktree.test.ts: split `localFilterCommands` in two. The fail-closed
branch is platform-free by construction and the base Windows log shows it
passing there; only the `a\nb` fixture is Windows-impossible, so only that
half keeps the gate.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* ci: say why the post-redirect autocrlf line is not a duplicate
Both workflows now run `git config --global core.autocrlf false` twice: once
before the checkout and once inside the test step, where HOME/USERPROFILE are
redirected to a freshly created empty directory. The second line therefore
writes a different global config than its twin, and on ci.yml's hosted
windows-2022 fallback the pre-checkout step never runs at all because it is
gated on `runner.environment == 'self-hosted'`.
It was the only one of the three occurrences with no comment, so deduping it
looks free and silently returns CRLF conversion to every git operation the
suites perform. Replaying no-ak-integration-ci.test.js's own assertions with
the second occurrence deleted gives identical indices and still passes, so no
test notices the removal.
Comments only. The ordering assertions search for the FIRST occurrence and
none of the added text matches a needle they look for; the 14 assertions in
no-ak-integration-ci.test.js still pass.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
---------
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* fix(core)!: read command hook timeout in seconds with a 600s default
Command hooks passed `timeout` to the timer as milliseconds, while HTTP
and prompt hooks read it as seconds, the settings schema described
seconds, and the hooks guide documented both. A command hook written
with `"timeout": 10` was killed after 10ms and failed open.
Command hook `timeout` is now read in seconds and defaults to 600s. A
value of 1000 or more is still read as milliseconds so existing settings
keep their meaning, and a debug-log warning names each such hook once.
Timeout errors report seconds. HTTP, prompt and function hooks are
unchanged. The schema description, generated JSON schema and every
command hook example in the guide now use seconds.
BREAKING CHANGE: a command hook `timeout` below 1000 is now seconds
rather than milliseconds.
Part of #11610
* fix(core): keep hook timeouts authoritative and surface legacy values
Review follow-up.
- Hook execution requests on the message bus no longer carry the bus's
60-second default deadline, so a hook is bounded by its own timeout
instead of being abandoned while it keeps running. Explicit caller
timeouts and other request types are unchanged.
- Command hooks on MessageDisplay, StopFailure and SessionDelete, which
outlive the CLI, default to 60 seconds instead of 600.
- Settings warnings now name each command hook whose timeout is still
read as milliseconds; the advice never suggests a seconds value that
would itself be read as milliseconds.
- The hooks guide scopes "seconds" to command, HTTP and prompt hooks and
notes async slot usage; shipped external-context examples use seconds.
- Tests pin the async registration and supervisor deadlines, and reset
the warning deduplication between cases.
Part of #11610
* docs(core): explain long command hook timeouts and blocking hold time
A command hook timeout of 1000 or more is still read as legacy
milliseconds, so a value meant as a long timeout in seconds, such as 1800
for 30 minutes, ends up as 1.8 seconds. The startup warning now also says
how to keep the value that was meant as seconds, and the hooks guide
explains that long timeouts stay in milliseconds. The guide also notes that
a synchronous hook on an event that waits for its result holds the turn
until it exits or times out, 600 seconds by default.
* fix(core): bound signal-less hook requests and cancel tool hooks on abort
The message bus now waives its default deadline only for hook execution
requests that carry an abort signal. Requests without one cannot be
cancelled, so they keep the 60-second deadline instead of waiting on the
hook's own timeout.
PreToolUse, PostToolUse and non-interrupt PostToolUseFailure hooks now
receive the tool's abort signal, in the payload and as the request signal,
so an abort stops the hook and releases the wait. Interrupt reports keep no
signal because it is already aborted there. The UserPromptSubmit hook gets
the send signal, and a send aborted during or right after that hook ends as
an abort instead of recording or sending the prompt.
MessageDisplay deliveries pass the turn signal to the request, warn when the
bus reports a failed hook execution, and stay quiet when the turn was
cancelled.
A command hook timeout written as a numeric string is read like the number
it holds instead of falling back to the default.
The startup warning for legacy millisecond timeouts is removed from this
change and tracked in #11675; the hooks guide now explains how to find such
hooks. Async hook timeout messages report seconds, the remaining first-party
millisecond values in integration fixtures and design docs are rewritten in
seconds, and the async hooks bullet names the 60-second default on events
whose hooks outlive the process.
* fix(core): keep the 60 second command hook default and drop hook bus signal threading
Raising the command hook default to 600 seconds forced two rounds of
reconciliation with the 60 second and 15 second bus deadlines: first by
waiving the deadline, then by threading abort signals through the tool
and prompt hook call sites. Each round produced new regressions (payload
vs request signal, already-aborted failure reports, unmigrated arity
assertions, orphaned hook children, cancels recorded as hook errors). The
default change and the cancellation work move to a follow-up issue, and
this change keeps only the unit.
- Command hook timeouts stay in seconds with a 60 second default, the
same duration as before; values of 1000 or more keep their legacy
millisecond meaning, and numeric strings are still coerced. The
separate default for hooks that outlive the process is gone because it
now equals the default.
- MessageBus, tool hook triggers, the scheduler, the UserPromptSubmit
request, the MessageDisplay dispatcher and their tests are back to main.
- An unusable timeout such as "30s" is named in the debug log with the
default it was replaced by, like a legacy millisecond value.
- Timeout warnings are recorded as sent only once debug logging can write
them, and are deduplicated per session.
- Async hook timeout messages and a real spawned hook with timeout 1 now
pin the seconds conversion.
---------
Co-authored-by: qwen-code-dev-bot <qwen-code-dev-bot@users.noreply.github.com>
* fix(acp): Preserve submitted prompt provenance for auto recall
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* fix(acp): Omit submitted_prompt on channel-classified turns (#11455)
Channel turns are machine-relayed deliveries (loop jobs, webhook tasks,
adapter-synthesized events), so nothing on them crossed a submission
boundary. Since submitted_prompt presence alone gates Auto Recall's
outbound provider search, emitting it there ran retrieval on unattended
turns and could publish composed wrapper text as user provenance. Gate
emission on a positive user-submission condition instead.
Also reconcile the producer-set contract this PR changed: hooks.md, the
Auto Recall READMEs, the in-product hook description with its locale
mirrors, and the recording payload comment now state the actual rule,
and the new design doc records the channel exclusion plus the
strict-decoder rollout warning.
* fix(acp): Require explicit submission provenance for auto recall
Carry original Web Shell composer text separately through admission and queues; keep background dispatches and undeclared requests ineligible. Reconcile hook and integration contracts and add regression coverage.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
---------
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Add an opt-in workspace-bound deletion profile with exact target reads,
full-text and scope verification, single-shot deletion, and absence checks.
Preserve full record identifiers and cover approval and failure boundaries.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* ci: give every workspace the shared-pool test timeout, not just five
`npm run test:ci --workspaces` runs 22 vitest projects and they all land on the
same shared ECS pool, where an identical suite takes about 5x longer depending
only on which host it draws (#10490). Five of those configs were given a raised
ceiling there, one at a time, as each package's flakiness became somebody's
problem: cli, core, acp-bridge, web-shell and vscode-ide-companion. Three more
carry a generous flat value (node-repl 60s, sdk-typescript E2E_TIMEOUT_MINUTES,
scripts/tests 90s).
The remaining fifteen were still on vitest's 5000 ms default: all eleven
channels packages, audio-capture, chrome-extension, webui and both
external-context integrations. That is 99 test files and roughly 3170 cases
whose only timeout on a contended host was 5s.
The workaround pattern was already visible in the tree — four tests had been
hand-patched past the default individually, each in its own commit:
integrations/external-context/src/auto-recall.test.ts 12s
integrations/external-context/src/provider-extension-local.ts 20s, 30s
packages/channels/base/src/ChannelBase.test.ts 8s
Every one of those is a case that needed more than 5s, found the hard way. This
raises the ceiling once, at the lane, instead of one test at a time.
Uses the `? 60_000 : undefined` form that acp-bridge and web-shell already use
rather than cli/core's `? 60_000 : 15_000`, so the change is confined to the
pool: off it these configs keep vitest's own default and a genuine hang on a
developer machine still fails in 5s, not 60s. 60_000 is the value the five
already-raised configs settled on.
The parity sweep in scripts/tests/unit-vitest-configs.test.ts now covers all 22
configs plus webui's function-form vite.config.ts, so a new workspace cannot
quietly join the lane on the 5s default. It asserts a floor rather than
equality, which lets scripts/tests (90s) and sdk-typescript (180s) keep their
own numbers, and a companion case pins that the off-pool branch stays
`undefined`. Verified both ways: the sweep reports 60000 for every config under
an `ecs-qwen-*` stub, `undefined` off it, and fails when the ceiling is removed
from any single config.
No test, fixture or production code changes; a test can only get more time
than before, and only on the pool.
Prerequisite for quarantining the seven raw wall-clock budgets that live in
these packages (#10912): channels/base and channels/dingtalk guard quadratic
stalls at 1000 ms whose measured regression cost is ~4.1s, so under the old 5s
ceiling there was no room to relax those bounds for a contended host at all.
* fix(ci): close the shared-pool timeout pin's own coverage holes
The review found four ways the pin could certify a green the lane does
not actually have. Close each one in the pin itself:
- packages/qwen-live defines test:ci and already runs on the pool lane,
but was absent from the swept map; register it (its 60s ceiling is
unconditional, so it stays out of the off-pool sample).
- Run every on-pool assertion under two runner names sharing only the
documented ecs-qwen- prefix, so a gate narrowed past the prefix fails
instead of passing on the stub's own name.
- Stub QWEN_SCRIPTS_TEST_TIMEOUT_MS and E2E_TIMEOUT_MINUTES alongside
RUNNER_NAME: scripts/tests and sdk-typescript derive their ceiling
from those knobs, so the pin must test the configs' logic, not the
ambient environment. The scripts-suite knob test's unset arm now
deletes the variable for real (stubEnv undefined) instead of relying
on the ambient value being absent.
- Extend the off-pool sample to every gated ternary (all fourteen this
PR gates plus acp-bridge/web-shell, which carried the shape already,
plus the webui function form), so a flat 60s in any of them fails.
Co-authored-by: Qwen-Coder <qwen-coder@alibaba-cloud.com>
Patrol-Run: qwen-pr-closeout/jmtlz4ubdgq
* fix(ci): pin the unset-RUNNER_NAME state and correct the pin's comment
Add an unset-state arm to the shared-pool timeout pin: the off-pool test
only stubbed a foreign RUNNER_NAME, so a ternary treating a missing
variable as pool (`?? true`, `=== undefined || startsWith(...)`) passed
every test while developer machines — which run with RUNNER_NAME unset —
silently moved to the 60s ceiling. The new arm deletes the variable via
`vi.stubEnv(..., undefined)` and samples every gated ternary plus the
webui function form. Mutation check: channels/base mutated to `?? true`
fails only the new arm; restored, the suite is green.
Reword the comment above configModules: the pin does not replace the
hand-patched per-test timeouts (auto-recall 12s, provider-extension-local
20s/30s, ChannelBase 8s). A per-test timeout outranks the config-level
field and stays load-bearing off the pool, so the pin guards the
config-level ceiling only.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmtme4yqxhl
* test(ci): pin the shared-pool guard's own coverage instead of sampling it
Three holes in the guard added for the #10490 flake class, all in the guard
rather than in any config:
cli and core were kept out of the off-pool sample on the stated grounds that
they pin a lower value, but nothing asserted that value — flattening either
ternary to the pool number passed the whole file, and a real hang off CI would
have surfaced at 60s instead of 15s. Both off-pool arms now assert 15s.
Those two arms also carried verbatim copies of the same 16-entry sample, so a
newly gated workspace had to be registered in three places, and missing one
left it with a pool floor but no off-pool assertion. One shared list and one
helper now back both arms.
configModules was hand-maintained with nothing cross-checking it against the
workspace set, while `npm run test:ci --workspaces` runs whatever the root glob
resolves — so a new workspace with a test:ci script could join the lane on
vitest's 5s default with the guard green. The map is now checked against the
repo's own workspace resolver, one-directionally.
* refactor(ci): share the test:ci workspace selector between both suites
The shared-pool timeout cross-check re-implemented the test:ci workspace
selector that release-workflow.test.js already carried as
getTestCiWorkspaces: same getWorkspacePackageJsonPaths root glob, same
scripts?.['test:ci'] filter. Two copies of the selection could drift
and let the two suites pin different workspace sets.
Extract the selection once into scripts/workspaces.js as
getTestCiWorkspacePaths(root) and consume it from both tests; the
release-workflow site keeps only a pair adapter attaching the parsed
package.json its assertions read. Pure extraction with no behavior
change: both selectors resolved the same 23 workspaces before and
after.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmtmxfessij
* refactor(ci): rename selector to getTestCiWorkspacePackageJsonPaths
The selector returns workspace package.json paths, so carry the same
PackageJson qualifier as its sibling getWorkspacePackageJsonPaths
instead of making every caller privately know the entries end in
/package.json. Updates both consumers added in this PR.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmtnaadh9j8
* test(scripts): pin the test:ci workspace selector directly
Every consumer derives its workspace set from the selector, so a
filter mutation that drops a subset stays invisible to all of them.
Add an exact-set fixture pin next to the getWorkspacePackageJsonPaths
tests, with the with-ci workspace outside packages/ to mirror the
integrations/* layout. Verified red against both an over-inclusion
mutant (filter -> true) and a partial-drop mutant.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmtnaadh9j8
* test(scripts): make the selector pin and off-pool arms witness-bearing
Addresses the two low-severity coverage findings from the sandboxed
verify report (comment 5548150043), both measured open at this head:
- Finding A: the exact-set pin mirrored only the flat integrations/*
layout, so a filter mutation dropping the nested packages/channels/*
subtree stayed invisible to all three selector consumers (mutant S3
survived 105/105). Mirror the nested layout in the fixture too:
explicit packages/channels/* entries in the root workspaces list
(packages/* does not match nested directories), one member with a
test:ci script and one without. S3 now fails the pin, naming it;
S1/S2/S4 stay caught.
- Finding B: OFF_POOL_DEFAULT and OFF_POOL_PINNED are hand-maintained
and nothing cross-checked them, so dropping a name silently removed
its off-pool assertion and a flattened ternary still passed the
on-pool floor (mutants G5/G6 survived). Add a partition-
exhaustiveness pin: every configModules entry must sit in exactly
one off-pool arm and every arm entry must exist in the map. Both
mutants now fail it.
No production logic changed; pins and fixtures only.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Patrol-Run: qwen-pr-closeout/jmtnn5c4cjw
---------
Co-authored-by: Qwen-Coder <qwen-coder@alibaba-cloud.com>
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* fix(ci): extend the vitest RPC-timeout exemption to every unit suite (#10438)
* refactor(ci): collapse duplicated vitest exemption rationale to witness pointer (#10438)
* refactor(ci): extend vitest rationale pointer consolidation to remaining unit configs (#10438)
* fix(external-context): read the response body with a reader, not for-await
Async-iterating a ReadableStream needs [Symbol.asyncIterator] on the
TYPE, and whether it is there depends on which lib set the program
resolves — @types/node's stream has it, the DOM lib's needs
lib.dom.asynciterable. That resolution flipped underneath this file on
2026-08-08: #8693 installed @types/jsdom at the root, vitest's types
pull the jsdom types in wherever they exist, and jsdom's carry
/// <reference lib="dom" />. #8693 shipped the tsconfig `types` guard in
the same commit, so main stayed green — but the guard travels with the
BRANCH while node_modules travel with the TRUSTED BASE in the autofix
verification build, so every managed branch behind #8693 failed that
build with TS2504 on this line. Two legs measured on run 31276008548:
63 minutes of accepted agent work discarded per round, 18 more minutes
burned by a repair step that cannot fix a failure outside the PR's diff
(#8614 reached attempt 13 that way; #8616 died identically).
Reproduced locally in both directions before changing anything:
@types/jsdom installed + guard removed = the gate's exact error,
character for character; with the reader loop the same poisoned setup
builds clean. The guard stays — belt and suspenders — but the build no
longer depends on it, or on which lib set any future environment
resolves.
Behavior is unchanged and now pinned by tests the file never had:
multi-chunk assembly, the exact MAX_RESPONSE_BYTES boundary (bound is
strictly-greater), invalid-UTF-8 rejection, and the easy one to drop in
this rewrite — cancelling the stream on early exit, which `for await`
did implicitly via iterator return(). Mutation-tested: removing the
cancel fails exactly that test against an endless producer.
The package's other for-awaits iterate process.stdin (a Node stream,
async-iterable in every lib set) and are untouched.
* fix(external-context): await stream cancellation before rejecting the request
On early exit from the reader loop (the oversize throw) cancellation was
started fire-and-forget, so postJson() rejected while the stream's
teardown was still settling — `for await` had awaited its implicit
iterator return() before propagating. An immediate retry could overlap
the previous response transport's unfinished cancellation. Await
reader.cancel() before releaseLock(), and pin the sequencing with a
deferred-cancel regression test that fails against the fire-and-forget
form.
Also cover read() rejecting after a partial chunk was received: the
error maps to the request-did-not-complete transport error rather than
EOF-then-parse of the partial JSON, and the reader lock is still
released.
* fix(external-context): drop the types guard the reader rewrite made obsolete
The `"types": ["node"]` override existed solely to keep @types/jsdom's
lib.dom out of this program while http-client.ts read the response body
with `for await` — the DOM lib's ReadableStream is not async-iterable,
and the flip broke the build with TS2504 (#8693). The reader loop that
replaced the `for await` types identically in every lib set, so the
guard is no longer load-bearing: with it removed, lib.dom re-enters the
program and the package still builds cleanly. Drop it with its stale
comment instead of leaving maintainers two contradicting stories about
whether it is needed.
Also export MAX_RESPONSE_BYTES and import it in the boundary tests
instead of re-declaring it locally, so the tests pin the real constant
rather than a copy that can silently drift.
* test(external-context): make the invalid-UTF-8 test pin fatal decoding
---------
Co-authored-by: verify <verify@local>
Co-authored-by: qwen-code-dev-bot <qwen-code-dev@service.alibaba.com>
* fix(integration-tests): make the project typecheckable and fix what that found
`tsc -p integration-tests/tsconfig.json` could not run at all. The config
carried a `"//"` documentation key inside `compilerOptions.paths`, and every
value there must be an array, so tsc aborted with TS5063 before checking a
single file. Nothing in CI runs it either, so the directory has been
unchecked for its whole life -- which is how PR #8620 shipped an
`integration-tests/cli/qwen-serve-streaming.test.ts` that referenced an
undeclared `REPO_ROOT`, swallowed the ReferenceError in a bare catch, and
reported a green skip for a security regression test.
Moving that note out of `paths` exposed 404 errors. Three more config
defects accounted for 353 of them:
- `composite: true` is inherited from the root config for the packages that
are actually referenced. Composite requires every file in the program to
appear in `include`, and these tests import package sources by relative
path, so it produced 324 TS6307. Nothing references this project and it
emits nothing, so it is now `composite: false`.
- The root `lib` is ES2023 only. The suite drives browser-side code in
`terminal-capture/` and pulls SDK sources that name `WebSocket` and
`HeadersInit`, so 21 identifiers resolved to nothing. Now DOM +
DOM.Iterable + ES2023, matching packages/cli.
- Workspace packages resolved through `packages/core/dist` via a project
reference, so with core unbuilt the checker reported a dozen members as
missing from `Storage` that are right there in the source. They now
resolve from source through `paths`, mirroring packages/cli, and the
reference is gone.
node-pty declares `types` at the top level but its `exports` map is a bare
string with no `types` condition, so nodenext never reached the
declarations and every pty handle degraded to `any` -- which is what
silently untyped the `data` and `exitCode` callbacks in test-helper.ts. It
now resolves through `paths` as well. `@types/jsdom` is added for the one
file that uses it; DefinitelyTyped has no release matching jsdom 26 (it
jumps 21 -> 27), so this pins the current 28.x.
Two real defects fell out of the remaining 51:
- write_file.test.ts built a detailed tool-call failure message and passed
it to `toBeTruthy()`, which takes no arguments. It was discarded on every
failure, leaving only a bare literal.
- Two terminal-capture scenarios set `gif: true` inside `streaming`, where
the runner never reads it. It is a scenario-level switch.
The rest was making an existing `undefined` visible. `readToolLogs()`
promised `name: string` for fields copied straight out of telemetry
attributes that nothing validates; the stdout fallback can promise them,
the telemetry branch cannot, and claiming otherwise just moved the
`undefined` past the type checker into the assertions.
This is type resolution only. `integration-tests/vitest.config.ts` keeps
its own hardcoded aliases onto the built SDK bundle, so the suite still
exercises the published-bundle shape at runtime.
Not wired into CI here, but not for cost reasons: a cold run of
`tsc -p integration-tests/tsconfig.json` takes about 106s on an idle
developer box. The program is 2679 files, of which 103 are integration
tests and roughly 1100 are package sources their own projects already
check, so there is duplicated work available to reclaim by resolving the
packages from their built declarations -- but at ~106s it is already cheap
enough to gate on as-is.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(integration-tests): isolate jsdom types and complete source-resolution paths
Address review round 1:
- external-context: override `types` to ["node"]. The root @types/jsdom
entered its program through vitest's optional jsdom types and injected
lib dom, flipping @types/node's fetch globals to DOM variants whose
ReadableStream is not async-iterable (TS2504 in http-client.ts), which
failed every CI job during the npm ci prepare build.
- integration-tests tsconfig: explicit nodenext paths entries for every
workspace subpath the program imports (sdk/daemon, 19 acp-bridge
subpaths, core goalWire/memoryScopes/userPromptSubmitContext, webui
daemon-react-sdk, channel-base); drop the dead `*` wildcards; include
**/*.tsx. Typechecks green with the source packages' dists removed.
- Relax noPropertyAccessFromIndexSignature in integration-tests and
revert the six bracket-access rewrites it forced in SDK sources.
- channel-plugin: import channels/base from src and map
@qwen-code/channel-base to source so both declarations agree.
- qwen-serve-streaming: asAccepted delegates to the SDK's exported
isNonBlockingAccepted type predicate instead of a drifted copy.
- sleep-interception: tighten blocked predicates to success === false
and fix the comment describing them.
- Declare jsdom at the root next to @types/jsdom.
* fix(integration-tests): complete source-resolution paths and restore single channel-base instance
Address review round 2:
- Map the eight builtin channel adapters and web-templates to source.
channel-registry.ts and html.ts still resolved them through their
exports maps to dist, so the typecheck's build-independence was
incomplete: on a tree without built dists it failed with the exact
9 x TS2307 the maintainer verification measured.
- channel-plugin.test.ts: import @qwen-code/channel-base by bare
specifier instead of a relative src path. At runtime the test and
plugin-example now resolve the same dist/index.js through the
exports map, restoring the single ChannelBase / SessionRouter
instance the relative src import silently split; type resolution
still maps to source through paths, and vitest.config.ts keeps
pointing e2e runs at the built bundles.
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Shaojin Wen <shaojin.wensj@alibaba-inc.com>
Co-authored-by: qwen-code-dev-bot <qwen-code-dev@service.alibaba.com>
Co-authored-by: qwen-code-dev-bot <qwen-code-dev-bot@users.noreply.github.com>
* fix(external-context): harden MCP dependencies
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* fix(external-context): drop no-op MCP override, raise SDK floors (#8206)
Remove the `@modelcontextprotocol/sdk@^1.30.0` -> `@hono/node-server`
override: resolution with and without it is byte-identical because the
SDK's own `^1.19.9 || ^2.0.5` range already selects 2.0.12, and
mobile-mcp's exact SDK pin (not this entry) keeps its nested Hono 1.
Raise the `@modelcontextprotocol/sdk` floor to `^1.30.0` on the packages
that actually instantiate the Hono-backed transport (cli, core,
sdk-typescript, vscode-ide-companion) so the hardened constraint lives in
the manifests where the code runs, matching the PR's stated intent.
---------
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* feat(external-context): add submitted-prompt auto recall
Add an opt-in Hook-only profile that derives bounded retrieval queries from submitted prompt provenance while preserving the existing on-demand MCP contract.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* fix(external-context): harden auto recall query sanitization (#7877)
Address review feedback on the submitted-prompt auto recall Hook:
- Bound the sanitizer input before the redaction regexes run so a
worst-case prompt cannot drive the assignment regex into quadratic
backtracking that blocks the event loop past the wall-clock budget.
- Test the whole assignment for secret names so a leading label such as
"Deploy failed:" can no longer claim the match and leak an api_key=.
- Skip the interactive E2E under container sandboxes (docker/podman),
matching the cron-interactive precedent.
- Restore real undici coverage for a malformed proxy environment value.
- Make the wall-clock-budget test exercise the internal timer rather than
the provider timeout, and give the backtracking regression test a shape
that actually backtracks.
- Clarify that the v2 top-level timeoutMs applies only to the on-demand
MCP path, and note session-lifetime context accumulation in the design
doc.
* fix(external-context): complete secret redaction, guard MCP config version (#7877)
Anchor the secret keyword to the name that owns the separator so a leading
prose label can no longer claim the match. This redacts spaced separators
(api_key = sk-...) and inline JSON ({"api_key": "..."}), and stops
over-redacting ordinary prose such as "readme: token refresh flow".
Also reject non-version-1 configs in runMcp with a clear startup error so an
auto-recall (v2) config cannot silently expose a second retrieval surface.
---------
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Co-authored-by: Qwen Code Autofix <qwen-code-autofix@users.noreply.github.com>
Co-authored-by: qwen-code-dev-bot <qwen-code-dev@service.alibaba.com>
