feat(integrations): add retrieval-only external context search - #7586
Conversation
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
E2E test reportTested commit: Extension loading
Behavioral verification
Repository verification
Limitations
中文测试报告测试提交： 扩展加载
行为验证
仓库验证
限制
|
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
Preserve provider timeout classification, reject ambiguous Mem0 statuses, release rejected response bodies, and clarify credential and workspace deployment boundaries. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Final broad auditAudited commit: The final implementation and proposal were re-audited across architecture boundaries, provider-side authorization, repository isolation, configuration and credential handling, HTTP failure paths, Mem0 semantics, Hook/MCP behavior, deployment scope, packaging, tests, compatibility, maintainability, and simpler alternatives. The audit fixed four concrete classes of problems:
Verification passed: 47 integration tests, 3 focused Core scheduler tests, compiled stdio MCP plus command Hook Fake Provider E2E, isolated Qwen extension link/user-disable/workspace-enable discovery, full repository build, typecheck, lint, lockfile check, package dry-run, and diff/format checks. The runtime critical-advisory threshold passed; npm reported existing non-critical repository dependency advisories, but no newly reachable issue was found in this stdio-only integration. After the last fix, two consecutive open-ended reviews of the final diff found no new clear, actionable issue. 中文审计说明审计提交： 最终实现与 proposal 已从架构边界、Provider 端鉴权、仓库隔离、配置与凭证处理、HTTP 故障路径、Mem0 语义、Hook/MCP 行为、部署 scope、打包、测试、兼容性、可维护性和更简单替代方案等维度重新完成全面审计。 本轮修复了四类明确问题：
验证全部通过：47 个 integration 测试、3 个 Core scheduler 定向测试、编译后 stdio MCP 与 command Hook 的真实进程 Fake Provider E2E、隔离 Qwen 环境中的 link/user-disable/workspace-enable 发现验证、全仓 build、typecheck、lint、lockfile check、package dry-run，以及 diff/format 检查。运行时 critical 漏洞阈值通过；npm 报告了仓库已有的非 critical 依赖公告，但未发现该 stdio-only integration 新增的可达问题。 最后一次修复后，又对最终 diff 完成两轮连续的无方向复审，没有发现新的明确可执行问题。 |
gwinthis
left a comment
gwinthis
left a comment
There was a problem hiding this comment.
Architecture Review: COMMENT (C=0)
Summary
Large feature (+2980/-0) adding a Direct External Context Provider integration — a read-only context_search MCP tool with optional context_remember write tool, adapter-based provider support (Mem0 V3, Generic HTTP V1), and admin-owned security selectors.
Architecture Assessment
Strengths:
- Extension, not Core API — built from monorepo as a Qwen extension, not a Core API. Keeps Core unchanged, enables per-workspace opt-in.
- Admin-owned security selectors — model tool arguments cannot set tenant, user, repository, namespace,
app_id, or arbitrary filters. These are fixed by configuration, not model discretion. This is the key security boundary. - Trust boundary explicitly documented — one process, one configured provider, one repository corpus, no model-controlled security selectors. Explicitly does NOT claim trusted personal identity, per-user audit, per-document ACL, DLP, credential isolation from same-UID tools, retention/deletion governance, or multi-workspace serving.
- Untrusted JSON rendering — provider responses are rendered as bounded JSON under
UserPromptSubmit.additionalContext, not as trusted system instructions. - Fail-open automatic recall — provider failures skip recall and the Qwen request continues. Sanitized bounded query: fenced code and credential-shaped values are stripped before sending to provider.
- Write safety — Mem0 writes never retried or polled, report only
acceptedorunknown. Generic HTTP has no write protocol.PreToolUseconfirmation hook for shared-memory writes. YOLO mode required for non-interactive.
Scope observations (non-blocking):
- "Direct Profile v1" requires built monorepo checkout — not self-contained as npm tarball
- Credential visible to same-UID processes is acknowledged as a known limitation
- Decision boundary with governed Gateway/Orchestrator Profile (#7449) is clearly drawn
Pattern
Admin-owned security selectors for model-facing tools: When a tool exposes provider-specific parameters (tenant, user, namespace) that are authorization boundaries, fix them in admin-owned configuration — never let the model choose them. The model can choose query and limit; it cannot choose tenant_id or app_id. This turns the tool's parameter surface into a non-authorization boundary, keeping the trust model simple.
中文说明
架构评审：COMMENT (C=0)
概要
大型功能（+2980/-0）：Direct External Context Provider 集成。只读 context_search MCP 工具 + 可选 context_remember 写入工具，适配器支持 Mem0 V3 和 Generic HTTP V1。
架构评估
- 扩展而非 Core API — 从 monorepo 构建为 Qwen 扩展
- 管理员拥有的安全选择器 — 模型不能设置 tenant/user/repository/namespace — 由配置固定
- 信任边界明确文档化 — 一个进程、一个 provider、一个仓库语料库
- 不可信 JSON 渲染 — provider 响应作为有界 JSON 渲染
模式
模型工具的管理员拥有安全选择器： 工具暴露的授权边界参数（tenant、user、namespace）由管理员配置固定，不让模型选择。模型只能选 query 和 limit。
— qwen3.7-max via Qwen Code /review
Limit Phase 1 to one provider-bound search tool, remove hooks and writes, and document the direct profile's actual permission and isolation boundaries. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
doudouOUC
changed the title
Phase 1 E2E validationThis report supersedes the earlier E2E comment for commit
Not validated here: a live production Mem0 project, Windows runtime behavior, Linux runtime behavior, or a standalone tarball deployment. The integration remains a private monorepo workspace. 第一阶段 E2E 验证本报告替代基于提交
本轮未验证：真实生产 Mem0 Project、Windows 运行时、Linux 运行时或独立 tarball 部署。该集成仍是 monorepo 内的私有 workspace。 |
Phase 1 scope and final auditThis comment supersedes the earlier final-audit comment for commit The PR now provides only on-demand external retrieval through The audit corrected several boundary and compatibility issues:
After the last tracked fix, two consecutive independent, broad diff audits found no remaining clear, actionable local code or documentation issue. The final tracked diff and its verification were reviewed together; 36/36 tests and all build, typecheck, lint, lockfile, packaging, and fake-provider checks pass. This is deliberately not the full governed design from #7449 or the complete roadmap in #7585. Identity, per-user or per-document authorization, DLP, writes, automatic recall, immutable approvals, compliance audit, and multi-workspace serving remain outside this PR. 第一阶段范围与最终审计本评论替代基于提交 本 PR 现在只通过 审计修正了以下边界与兼容性问题：
最后一次受跟踪修复完成后，两轮连续、独立、无方向的完整 diff 审计均未发现剩余的明确可执行本地代码或文档问题。最终 diff 与验证证据已一并复核；36/36 测试以及 build、typecheck、lint、lockfile、打包和 Fake Provider 检查全部通过。 这不是 #7449 的完整受管设计，也不是 #7585 全部路线图的实现。身份、逐用户或逐文档授权、DLP、写入、自动召回、不可绕过审批、合规审计和多 workspace serving 仍不在本 PR 范围内。 |
Pin the managed MCP source through an administrator-owned command-line configuration, document the Direct Profile trust boundary, and remove unused logging/runtime abstractions. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
|
Final multi-route audit completed on Changes made from the audit:
Verification:
已在 本轮修正了受管 MCP 同名覆盖、 最终结果：External Context 34/34 测试、workspace 与仓库级 build/typecheck/lint、lockfile、格式、diff check、dry-run package、编译后 stdio MCP E2E 全部通过；架构/正确性、安全/协议、测试/故障/打包三路审计均为 CLEAN，最后一次修复后又取得两轮连续清洁架构复审。 |
doudouOUC
left a comment
doudouOUC
left a comment
There was a problem hiding this comment.
Reviewed by checking out the branch and running it, not just reading the diff. Verification I did: vitest run → 34/34 pass, tsc --noEmit clean, tsc --build clean, eslint integrations/external-context/src clean. So the stated test/build/lint evidence holds up.
The security envelope is the strong part of this PR and I did not find a hole in it: model input really is confined to query, redirect: 'manual' prevents credential forwarding, the response is bounded both by declared content-length and by streaming, invalid UTF-8 is rejected fatally, cancellation propagates, and no provider detail escapes into the tool result. The threat model in the README is unusually honest about what the Direct Profile does not give you.
What I did find are correctness bugs in the data path — the part that decides which retrieved results the model actually sees. I reproduced each one against the compiled dist/ with a loopback provider; the reproductions are in the inline comments. The theme is that both the parse layer and the render layer fail silently and destructively: valid content gets dropped or blanked, and the model receives items: [] or content: "" with no way to tell that from "the corpus genuinely has nothing." For a retrieval tool that is the worst failure mode, because the model will confidently answer as though no context exists.
The existing tests don't catch these because every fixture is small and well-formed — no null optional fields, no long documents, no escape-heavy content. Suggest adding cases for exactly those.
Grouping the findings by priority:
Should fix before merge (silent data loss):
parseItemFieldsrejects a whole item when an optional field is malformed —score: null, or acontent/title/uriover its cap. Reproduced: item vanishes, tool returns[].trimNewestItemToBudgetmixes units and emitscontent: ""items. Reproduced with escape-heavy content:[999, 811, 0, 0, 0].MAX_ITEM_CONTENT_CHARS * MAX_ITEMS = 5000 > MAX_RENDERED_CHARS = 4000is structurally unsatisfiable, so the tail item is always degraded.- Provenance
uriis the first field dropped under budget pressure — the field most needed for citation, whilescoreis never dropped.
Worth fixing (operability / Simplicity First):
5. Local query-validation failures are reported as provider failures.
6. Startup errors discard already-sanitized ConfigurationError messages, leaving administrators nothing to debug with.
7. The four-class provider error taxonomy has no non-test consumer.
Repo-level, needs maintainer sign-off: this adds a new top-level integrations/ tier to workspaces and to scripts/build.js, so every contributor's npm run build / test / typecheck now pays for a private integration that no shipped artifact consumes. That's a cross-cutting change to package.json + eslint.config.js + scripts/build.js + package-lock.json and per AGENTS.md deserves an explicit maintainer decision rather than riding along with the feature.
Details inline.
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
|
Addressed the latest review on commit
Verification on the exact commit:
|
Code Review — #7586
|
|
Thanks for the thorough review. I independently checked all four suggestions against
The Node-only |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed — no blockers. 1 Suggestion-level finding(s) could not be anchored to a changed line and were dropped; nothing further to act on here.
— qwen3.7-max via Qwen Code /review
Review: retrieval-only external context searchReviewed at What I verified (all passing)
I also ran a compiled stdio MCP E2E against a fake loopback provider ( Observed on the wire:
Integration points against Qwen Core that I confirmed rather than assumed:
1. Repo-fit: new top-level
|
Install an environment-aware dispatcher before the external context MCP server starts so enterprise egress proxy and NO_PROXY settings apply to provider requests. Document the managed launcher environment and cover startup wiring. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
|
Thanks for the detailed review. I independently checked every item against exact head
The remaining notes do not justify further scope here: config-file branch tests, TOCTOU hardening under the administrator-owned-config premise, license normalization, and redundant test assertions are non-blocking follow-up polish; Verification on the pushed fix: external-context tests 43/43, workspace typecheck, lint, formatting, lockfile check, workspace build, full repository prepare/build, and a real dispatcher probe confirming both proxy routing and Review thread resolution: 0/0. This feedback was a top-level PR comment, and there are currently no unresolved inline review threads. |
Re-review: proxy delta (
|
| Scenario | Proxy events | Provider hit | Result |
|---|---|---|---|
A — PR head, HTTP_PROXY set |
CONNECT 127.0.0.1:52101 |
1 | ✅ routed through proxy |
B — PR head, NO_PROXY=localhost,127.0.0.1,[::1] |
none | 1 | ✅ bypass works as documented |
C — control: same build, setGlobalDispatcher(...) line stripped |
none | 1 | ✅ proxy fully ignored |
C is the one that matters: without this commit the proxy is invisible, so the change is doing real work. It also confirms the cross-instance trick holds — userland undici's setGlobalDispatcher does reach Node's built-in fetch (shared Symbol.for('undici.globalDispatcher.1')), same as Core's packages/core/src/config/config.ts wiring. Valid payload returned under untrusted_external_context in all three, stderr "" throughout.
The new unit test is also load-bearing — mutating main.ts to drop the call fails it:
AssertionError: expected "spy" to be called with arguments: [ Any<EnvHttpProxyAgent> ]
Number of calls: 0 ❯ src/main.test.ts:39:33
No regression in the bounded-failure paths through a live proxy tunnel
The dispatcher swap is exactly the kind of change that quietly breaks abort/stream teardown, so I re-ran the failure matrix with traffic actually tunnelling through the proxy:
| Case | Provider requests | Upstream aborted | Tool result | stderr |
|---|---|---|---|---|
302 redirect |
1 (no retry) | — | External context search failed. |
"" |
500 + body UPSTREAM SECRET DETAIL |
1 | — | External context search failed. (no leak) |
"" |
streamed >1 MiB, no content-length |
1 | ✅ | External context search failed. |
"" |
| client cancels in-flight | 1 | ✅ | AbortError |
"" |
Cancellation still tears down the upstream socket through the tunnel, and there's still no retry. Gates: 43/43 tests, tsc --noEmit clean, eslint --max-warnings 0 clean, prettier --check clean on every changed file, npm run check:lockfile passes.
1. Low — a malformed proxy env now kills the MCP server with an undiagnosable message
new EnvHttpProxyAgent() throws at construction on an invalid proxy value:
HTTP_PROXY="not a url" -> TypeError: Invalid URL
HTTP_PROXY="http://" -> TypeError: Invalid URL
HTTP_PROXY=" " -> TypeError: Invalid URL
HTTP_PROXY="ftp://p:1" -> InvalidArgumentError: Invalid URL protocol...
HTTP_PROXY="" -> constructed OK (so the common empty case is safe)
Because the call sits inside the top-level try, that lands in the opaque bucket rather than the sanitized-configuration bucket. Observed end-to-end on all four bad values:
exit=1 stderr="[external-context] External context startup failed."
This is a behavior change introduced by this commit: previously a malformed HTTP_PROXY was simply ignored by Node's fetch; now it's fatal, and the message never mentions the proxy. In the managed-launcher model the admin owns that environment, so the realistic failure is an admin typo in HTTPS_PROXY producing a dead context_search tool with no signal pointing at the cause — which is precisely what the PR's own two-tier error design (actionable ConfigurationError vs. opaque unexpected) exists to avoid.
Suggested fix, keeping the value out of the message since proxy URLs can embed credentials (http://user:pass@proxy):
try {
setGlobalDispatcher(new EnvHttpProxyAgent());
} catch {
throw new ConfigurationError(
'Proxy environment configuration is invalid. Check HTTP_PROXY, HTTPS_PROXY, and NO_PROXY.',
);
}The existing catch already prints ConfigurationError.message verbatim, so this needs no other change.
2. Nit — lockfile resolves the new undici off the other two
Three workspaces declare the identical range, but the lockfile splits them:
integrations/external-context/node_modules/undici 7.29.0 (^7.28.0)
packages/cli/node_modules/undici 7.28.0 (^7.28.0)
packages/core/node_modules/undici 7.28.0 (^7.28.0)
node_modules/undici 7.27.2
npm ci therefore materializes a 4th nested copy that could have deduped onto the existing 7.28.0. No functional impact — these are separate processes — but pinning to 7.28.0 (or npm dedupe) drops an avoidable duplicate.
3. Note — the README's bracketed [::1] is right, and the conventional form silently fails
Worth keeping exactly as written, because it's a real trap. Against an IPv6 loopback provider (baseUrl: "http://[::1]:PORT"):
NO_PROXY=localhost,127.0.0.1,[::1] -> proxyEvents=[] ✅ bypasses
NO_PROXY=localhost,127.0.0.1,::1 -> proxyEvents=["CONNECT [::1]:..."] ❌ still proxied
An admin who reuses an existing NO_PROXY (curl and most tooling use the unbracketed ::1) silently gets their loopback traffic tunnelled. A half-sentence in step 5 noting the unbracketed form does not match would save someone an hour.
Also observed and worth knowing operationally: undici CONNECT-tunnels even plain http:// origins (CONNECT 127.0.0.1:52101 above, not an absolute-form POST). Corporate proxies commonly restrict CONNECT to :443, so an HTTPS provider on a non-standard port may be refused by the proxy even though the config is valid. Not a code issue — it's just the reason the NO_PROXY guidance in step 5 is load-bearing rather than optional.
Previously deferred — accepting the scope call, one factual update
No objection to deferring these; flagging only that the tsconfig item now covers this delta's own code. Re-confirmed on 388be23ac: exclude: ["src/**/*.test.ts"] also governs tsc --noEmit, so appending const x: number = "definitely not a number"; to the new main.test.ts still leaves tsc --noEmit at exit 0. That new test is the one file relying on non-trivial types (importOriginal<typeof import('undici')>()), so it's the least-checked new code in the PR. A tsconfig.build.json split remains the right follow-up.
The Generic HTTP /v1/context/search path assertion is likewise still absent from the unit tests, though my compiled stdio E2E above exercises the real path — so the risk is regression detection, not current correctness.
Verdict
Merge-ready. The enterprise proxy gap from last round is properly fixed and I confirmed it with a control build rather than taking the diff's word for it, and the fix doesn't regress any bounded-failure, cancellation, or redaction behavior. Item 1 is a genuine (if small) new failure mode and is the only thing I'd suggest landing before merge; items 2–3 are optional polish.
中文说明
复审：代理修复增量（89d46604a → 388be23ac）
本轮只审阅新增的 fix(integrations): honor provider proxy settings 一个提交，外加自定义全局 dispatcher 可能破坏的路径的回归验证。在隔离 worktree 中基于 388be23ac 验证，并安装了锁定的 undici@7.29.0。
我上轮提出的代理缺口确实已经修复——通过实测 A/B 对照确认，而不是只读 diff。 新引入一个约 4 行即可修复的小问题，其余都是细节建议。
修复确实生效（实测 A/B）
用真实 stdio MCP（Client + StdioClientTransport）驱动编译产物 dist/main.js，配合 loopback Generic HTTP Provider 和支持 CONNECT 的本地代理：
| 场景 | 代理事件 | Provider 命中 | 结果 |
|---|---|---|---|
A — PR head，设置 HTTP_PROXY |
CONNECT 127.0.0.1:52101 |
1 | ✅ 经过代理 |
B — PR head，NO_PROXY=localhost,127.0.0.1,[::1] |
无 | 1 | ✅ 绕过行为与文档一致 |
C — 对照组：同一产物，删除 setGlobalDispatcher(...) |
无 | 1 | ✅ 代理被完全忽略 |
关键是 C：没有本次提交，代理完全不可见，说明该改动是真正起作用的。同时也验证了跨实例机制成立——用户态 undici 的 setGlobalDispatcher 确实能作用于 Node 内置 fetch（共享 Symbol.for('undici.globalDispatcher.1')），与 Core 在 packages/core/src/config/config.ts 中的做法一致。三个场景都返回了合法的 untrusted_external_context 载荷，stderr 全程为 ""。
新增单测也是有效的——把 main.ts 中的调用删掉后该测试失败（Number of calls: 0）。
经过真实代理隧道后，各故障路径无回归
替换 dispatcher 正是容易悄悄破坏 abort/流关闭的改动，因此我让流量真正穿过代理隧道重跑了故障矩阵：
| 用例 | Provider 请求数 | 上游被中止 | 工具结果 | stderr |
|---|---|---|---|---|
302 重定向 |
1（无重试） | — | External context search failed. |
"" |
500 + body UPSTREAM SECRET DETAIL |
1 | — | External context search failed.（无泄漏） |
"" |
流式 >1 MiB，无 content-length |
1 | ✅ | External context search failed. |
"" |
| 客户端取消进行中的请求 | 1 | ✅ | AbortError |
"" |
取消仍能穿过隧道关闭上游连接，且仍然没有重试。各项门禁：43/43 测试、tsc --noEmit、eslint --max-warnings 0、所有改动文件的 prettier --check、npm run check:lockfile 全部通过。
1. Low —— 代理环境变量格式错误会让 MCP Server 以无法诊断的信息启动失败
new EnvHttpProxyAgent() 在构造时就会对非法代理值抛异常："not a url"、"http://"、" " 抛 TypeError: Invalid URL，"ftp://p:1" 抛 InvalidArgumentError；空字符串 "" 可正常构造（因此最常见的空值情况是安全的）。
由于该调用位于顶层 try 内，它落入了不透明错误分支而非 sanitized 配置错误分支。四个非法值端到端实测结果均为：exit=1，stderr="[external-context] External context startup failed."。
这是本次提交引入的行为变化：此前格式错误的 HTTP_PROXY 会被 Node fetch 直接忽略，现在则是致命错误，且提示信息完全没有提到代理。在受管启动器模型下环境由管理员掌控，因此现实中的失败场景是管理员在 HTTPS_PROXY 上打错字，导致 context_search 工具直接不可用且毫无线索——而这正是本 PR 自身的双层错误设计（可操作的 ConfigurationError vs. 不透明的意外错误）想要避免的情况。
建议修复如下，注意消息中不应包含变量值，因为代理 URL 可能内嵌凭证（http://user:pass@proxy）：
try {
setGlobalDispatcher(new EnvHttpProxyAgent());
} catch {
throw new ConfigurationError(
'Proxy environment configuration is invalid. Check HTTP_PROXY, HTTPS_PROXY, and NO_PROXY.',
);
}现有 catch 已经会原样打印 ConfigurationError.message，无需其他改动。
2. Nit —— lockfile 中新增的 undici 与另外两个版本不一致
三个 workspace 声明了完全相同的范围 ^7.28.0，但 lockfile 解析结果不同：integrations/external-context 为 7.29.0，packages/cli 与 packages/core 为 7.28.0，根目录为 7.27.2。因此 npm ci 会额外产生第 4 份嵌套副本，而它本可以复用已有的 7.28.0。由于是独立进程，没有功能影响；但固定到 7.28.0（或执行 npm dedupe）可以去掉一份多余副本。
3. Note —— README 中带方括号的 [::1] 是正确的，而常规写法会静默失效
建议原样保留，因为这是一个真实的坑。针对 IPv6 loopback Provider（baseUrl: "http://[::1]:PORT"）：NO_PROXY=localhost,127.0.0.1,[::1] 可以绕过代理；而 NO_PROXY=localhost,127.0.0.1,::1（不带方括号，curl 和大多数工具使用的形式）仍然会走代理。沿用既有 NO_PROXY 的管理员会在毫无察觉的情况下让 loopback 流量被隧道转发，建议在第 5 步补一句说明不带方括号的形式不匹配。
另外一个值得了解的运维细节：undici 对纯 http:// origin 也使用 CONNECT 隧道（上文观察到的是 CONNECT 127.0.0.1:52101，而非 absolute-form 的 POST）。企业代理通常将 CONNECT 限制在 :443，因此即使配置合法，非标准端口上的 HTTPS Provider 也可能被代理拒绝。这不是代码问题，只是说明第 5 步的 NO_PROXY 指引是必要的而非可选的。
关于此前已推迟的项目——认可范围判断，仅更新一处事实
不反对推迟这些项，只是说明 tsconfig 那一项现在也覆盖了本次增量自身的代码。在 388be23ac 上重新确认：exclude: ["src/**/*.test.ts"] 同样作用于 tsc --noEmit，因此在新增的 main.test.ts 末尾追加 const x: number = "definitely not a number"; 后，tsc --noEmit 仍然以 0 退出。而该新测试恰恰是唯一依赖非平凡类型（importOriginal<typeof import('undici')>()）的文件，也就成了本 PR 中检查最薄弱的新代码。拆分 tsconfig.build.json 仍是合适的后续处理。
Generic HTTP /v1/context/search 路径断言同样仍未加入单测，不过我上面的编译产物 stdio E2E 已实际覆盖该路径——因此风险在于回归检测能力，而非当前正确性。
结论
可以合并。 上一轮的企业代理缺口已被正确修复，并且我用对照产物而非仅凭 diff 做了确认；该修复也没有破坏任何边界故障、取消传播或脱敏行为。第 1 项是本次引入的一个真实（虽小）的新故障模式，是我唯一建议在合并前处理的问题；第 2、3 项属于可选优化。
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed — no blockers. Suggestions are inline.
— qwen3.7-max via Qwen Code /review
Classify proxy dispatcher construction failures as sanitized configuration errors so managed deployments can identify an invalid proxy environment without exposing proxy credentials. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
|
Thanks for the focused re-review. I independently reproduced the new proxy-construction failure against exact head
Verification for |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
No issues found. LGTM! ✅
中文说明
未发现问题。LGTM！✅
— qwen3.7-max via Qwen Code /review
Local verification round 3 —
|
| # | Round-2 finding | Sev | Status at de9d5f77d |
|---|---|---|---|
| 1 | Invalid HTTP_PROXY/HTTPS_PROXY → opaque External context startup failed. |
Medium | Fixed and verified load-bearing. 5 of 9 real-process cells flip from opaque to actionable; the new unit case fails against the pre-fix source (§3). |
| 2 | undici lockfile drift → a 4th nested copy |
Low | Stands, as the author documented. Physically confirmed after npm ci: node_modules/undici 7.27.2, packages/core 7.28.0, packages/cli 7.28.0, integrations/external-context 7.29.0. Author's reasoning (sibling workspaces cannot share a copy) is correct; not a merge blocker. |
| 3 | NO_PROXY needs the bracketed [::1] |
Nit | README is already correct; polish deferred. Re-confirmed that a garbage NO_PROXY (::1,%%%,[) never throws — so the new message names NO_PROXY even though it can never be the cause. Harmless as guidance. |
| 4 | UTF-16 vs code-point rendering budget | — | Author is right; disproved my suggestion empirically. A 5 × 3000 astral-emoji provider payload renders at String.length 3999 (2470 code points) with no lone surrogate — the ceiling holds in the unit it is written in. |
| 5 | Provider-timeout integration test (deferred) | Coverage | Supplied here: timeoutMs: 1000 aborts the in-flight provider socket at 1006 ms, provider-side abort observed, exactly 1 request, stderr empty. |
| 6 | tsconfig exclude hides test files from tsc --noEmit |
Low | Still open — now with concrete evidence (§6). Optional. |
2. Repository gates at this head
npm ci (PR lockfile, full build) ✓ · npm run build ✓ · npm run typecheck ✓ · npm run lint ✓ · root eslint integrations/external-context/src --max-warnings 0 ✓ · prettier --check on the delta ✓ · 44/44 workspace tests ✓. PR scope re-checked: 27 files, nothing outside integrations/, docs/design/, eslint.config.js, package.json, package-lock.json, scripts/build.js.
3. The new commit is load-bearing (real OS processes)
verify7586/proxy-startup.mjs spawns the compiled integrations/external-context/dist/main.js as a real process with real proxy environment variables and observes exit code + stderr + whether the MCP server actually came up. The control arm is the same file rebuilt from 388be23ac's main.ts (inner try/catch absent) — nothing else differs.
| cell | env | PR head de9d5f77d |
control 388be23ac |
|---|---|---|---|
| P1 | HTTP_PROXY='not a URL' |
exit 1 + Proxy environment configuration is invalid. Check HTTP_PROXY, HTTPS_PROXY, and NO_PROXY. |
exit 1 + External context startup failed. |
| P2 | HTTP_PROXY=' ' |
actionable | opaque |
| P4 | HTTPS_PROXY='ftp://proxy.internal:8080' |
actionable | opaque |
| P5 | lowercase http_proxy='not a URL' |
actionable | opaque |
| P6 | http://svc-account:<secret>@ bad host:3128 |
actionable, no credential/user/host in stderr or stdout | opaque |
| P0/P3/P7/P8 | none / '' / garbage NO_PROXY / valid proxy |
server starts, stderr empty | identical |
9/9 at head, 4/9 on the control. The new unit case is not vacuous either: reverting main.ts alone makes src/main.test.ts:63 fail with exactly the opaque string. Extra malformed forms that are now diagnosed rather than opaque: proxy.corp:3128 (scheme omitted — the most common admin mistake), //proxy.corp:3128, http://[::1:3128.
No regression to the round-2 proxy behaviour: with a valid HTTP_PROXY at a CONNECT-capable loopback proxy a real search still tunnels (CONNECT 127.0.0.1:<port> observed once), and NO_PROXY=127.0.0.1 still bypasses (no CONNECT, direct hit).
4. Protocol matrix against the compiled server — 19/19
verify7586/mcp-matrix.mjs: a real @modelcontextprotocol/sdk client over a real stdio child process, a real loopback provider, a real CONNECT proxy. Every cell asserts both sides of the wire — what the provider received (method, path, authorization, exact body, request count, socket abort) and what the model would see — plus that stderr stays empty.
- Tool surface is exactly
context_search, one argumentquery,destructiveHint: false. - Provider receives
POST /v1/context/search,Bearer <token>, body exactly{"query":"release notes captain","limit":5}from' release notes\n\tcaptain '; the model gets a 363-charuntrusted_external_contextenvelope. - Extra structured tool arguments (
app_id,filters,top_k,limit,baseUrl,authorization,threshold,rerank) never reach the provider — body unchanged, decoy origin gets 0 hits. - Every provider failure returns only
External context search failed.with exactly 1 provider request (no retry) and empty stderr: manual redirect (decoy target never contacted), declared oversize (content-length2 MiB), streamed oversize (chunked, nocontent-length), invalid UTF-8, invalid JSON, valid JSON with an invalid envelope, 429, 5xx. - Malformed items dropped, unknown provider fields stripped from the envelope.
timeoutMsabort and MCP client cancellation both abort the provider socket (provider-side observed), no retry.- Query bounds: 2000 code points forwarded; 2001 rejected with
-32602and the provider is never contacted (also for astral queries, i.e. 4002 UTF-16 units); whitespace-only rejected locally asSearch query must not be empty.
Mem0 V3 adapter, real module against a real loopback origin — 5/5: POST /v3/memories/search/, Token <key>, body exactly {"query":…,"filters":{"app_id":"repository-memory"},"top_k":5,"threshold":0.1,"rerank":false} even when the caller passes limit: 999; malformed results dropped; each adapter's prototype exposes only search; a non-loopback http:// origin is refused at construction.
5. End-to-end through the real built Qwen CLI — 7/7
verify7586/cli-e2e.mjs drives packages/cli/dist/index.js non-interactively against a scripted OpenAI-compatible endpoint (the wire oracle), with the administrator-owned --mcp-config pin, QWEN_CODE_SYSTEM_SETTINGS_PATH → managed settings, and a same-name decoy server in user settings. Because Qwen defers MCP tools behind ToolSearch, turn 0 is a real discovery round-trip.
- The tool is advertised in the deferred-tools listing under
#### external-contextasmcp__external-context__context_search(37 chars — matchespermissions.allow), revealed bytool_search, and present intools[]from the next turn on. - The pinned server answers: provider gets one
POST /v1/context/searchwith{"query":"release cadence thursday","limit":5}; the model receives the 319-char untrusted envelope; the decoy never runs. - Model-supplied corpus selectors are rejected one layer earlier than expected: Qwen Core's own Ajv parameter validation (
packages/core/src/utils/schemaValidator.ts:247,dataVar: 'params') refuses the call withparams must NOT have additional properties, so the adapter is never entered (the provider request count stays at 1). Defence in depth on top of the adapter's fixed fields. - Without
--mcp-config, the same-name user-settings server wins and answers (DECOY-SERVER-ANSWERED, 0 provider requests) — the README's central deployment claim, now demonstrated end-to-end rather than argued. - The allow rule is load-bearing: with it removed, the same call is declined (
Qwen Code requires permission to use "mcp__external-context__context_search", but that permission was declined) and the provider is never contacted, so an unmanaged session does not inherit automatic execution. examples/managed-mcp.json'sincludeTools: ["context_search"]spelling is correct and load-bearing: pinning a two-tool stand-in server under the same name shows only…__context_searchin the listing anddangerous_writegone; withoutincludeToolsboth appear.
6. Informational — not blockers
(a) Where the new message actually surfaces. Three arms with HTTP_PROXY='not a URL':
| arm | placement | result |
|---|---|---|
| 1 | in the launcher environment (as an admin would set it) | Qwen Core fails first: An unexpected critical error occurred: TypeError: Invalid URL with a raw stack from Core's own dispatcher install (packages/core/src/config/config.ts:2251-2258), exit 1. The integration's message is never reached. |
| 2 | scoped to the server via the pinned config's env |
CLI prints Warning: MCP server(s) failed to start: external-context. … Re-run with QWEN_CODE_DEBUG=1 to see per-server reasons.; the sanitized message is not on the terminal (mcp-client.ts:2181-2185 attaches the stderr listener only in debug mode). |
| 3 | same as arm 2, with --debug |
the sanitized message is in the debug log — the operator following the CLI's own instruction gets Proxy environment configuration is invalid. Check HTTP_PROXY, HTTPS_PROXY, and NO_PROXY. instead of External context startup failed. |
So the commit does pay off, through the documented debug path and when the MCP command is run standalone. Arm 1 is a pre-existing Core gap (this PR touches no packages/core code) and is the same bug class the author just fixed inside the integration — worth a separate follow-up applying the same sanitized-message treatment in Core. Optionally, one README line ("if the server fails to start, re-run with QWEN_CODE_DEBUG=1 to see the sanitized startup reason") would close the loop for admins.
(b) Well-formed but unreachable proxy. HTTP_PROXY=http://127.0.0.1:1 starts cleanly; searches then return only External context search failed. with empty stderr and zero provider hits. Correct per Phase 1's no-per-request-logging rule — just noting that the new diagnostic covers malformed values, not wrong-but-parseable ones.
(c) Test files are still outside tsc --noEmit (round-2 item 6, now concrete). With the workspace's own tsconfig.json and only exclude removed, the existing test files report two real errors: src/main.test.ts(33,3) — process.exitCode is string | number | null | undefined, not assignable to the local string | number | undefined — and src/mcp.test.ts(69,18) — result.content is unknown. Neither affects runtime (vitest transpiles only, 44/44 green) and eslint src does not flag them. A deliberately injected const probe: number = "…" in main.test.ts is likewise invisible to npm run typecheck and to eslint src. Dropping the exclude line (or adding a test-only tsconfig) would be a small hardening, and the file this round's commit touched is exactly one of the two affected.
Harnesses used
proxy-startup.mjs (9 cells × 2 builds) · mcp-matrix.mjs (19) · query-bounds.mjs (6) · mem0-wire.mjs (5) · cli-e2e.mjs (3 arms, 7) · include-tools.mjs (3) · proxy-edges.mjs (5) · operator-visibility2.mjs (3 arms). All mock-free: compiled dist/, real child processes, real loopback HTTP servers, real CONNECT proxy, real built CLI.
中文说明
本地验证第 3 轮 —— de9d5f77d（真实构建，无 mock）
以维护者身份在 macOS 15 / Node 22.23.1 上验证：独立 worktree detach 到精确 head de9d5f77d，用本 PR 的 package-lock.json 单独执行 npm ci（同时完成整个 monorepo 构建）。承接第 1 轮（#issuecomment-5076068086）与第 2 轮（#issuecomment-5076440681）；本轮聚焦新提交 fix(integrations): diagnose invalid proxy settings，并对整个接口做了一次从零开始的行为验证。
结论：可以合并。 8 个无 mock harness 共 43 项通过/失败断言全部通过；通过 A/B 证明新提交确实起作用；没有新的阻塞问题。下面两条可运维性说明仅供参考，其中一条属于 Qwen Core 的既有问题，与本 PR 无关。
1. 第 2 轮问题在新 head 的状态
| # | 第 2 轮问题 | 级别 | de9d5f77d 状态 |
|---|---|---|---|
| 1 | 非法 HTTP_PROXY/HTTPS_PROXY → 只输出不可诊断的 External context startup failed. |
Medium | 已修复且证明起作用。 9 个真实进程用例中 5 个从不可诊断变为可诊断；新增单测在修复前的源码上失败（见 §3）。 |
| 2 | undici lockfile 漂移 → 第 4 份物理副本 |
Low | 如作者所述，保持现状。npm ci 后物理确认：node_modules/undici 7.27.2、packages/core 7.28.0、packages/cli 7.28.0、integrations/external-context 7.29.0。作者的判断（同级 workspace 无法共用副本）正确，不阻塞合并。 |
| 3 | NO_PROXY 需要带方括号的 [::1] |
Nit | README 本身已正确，文档打磨延后。再次确认：非法 NO_PROXY（::1,%%%,[）不会抛错——所以新消息里提到 NO_PROXY，但它永远不可能是原因。作为提示无害。 |
| 4 | UTF-16 与码点计量的渲染预算 | — | 作者正确，我的建议被实测推翻。 5 × 3000 个星际平面 emoji 的 Provider 响应最终渲染为 String.length 3999（2470 码点），没有落单代理项——上限在其定义的单位上成立。 |
| 5 | Provider 超时集成测试（延后） | 覆盖率 | 本轮补上：timeoutMs: 1000 在 1006 ms 中止了正在进行的 Provider 连接，Provider 侧观察到 abort，请求恰好 1 次，stderr 为空。 |
| 6 | tsconfig exclude 使测试文件不被 tsc --noEmit 检查 |
Low | 仍然存在——本轮给出具体证据（§6）。可选。 |
2. 本 head 上的仓库门禁
npm ci（PR lockfile，完整构建）✓ · npm run build ✓ · npm run typecheck ✓ · npm run lint ✓ · 根级 eslint integrations/external-context/src --max-warnings 0 ✓ · 对 delta 执行 prettier --check ✓ · workspace 测试 44/44 ✓。范围复核：27 个文件，除 integrations/、docs/design/、eslint.config.js、package.json、package-lock.json、scripts/build.js 之外没有改动。
3. 新提交确实起作用（真实操作系统进程）
verify7586/proxy-startup.mjs 把编译后的 integrations/external-context/dist/main.js 作为真实进程启动，注入真实代理环境变量，观察退出码、stderr 以及 MCP Server 是否真的起来了。对照组是同一文件用 388be23ac 的 main.ts 重新编译（缺少内层 try/catch），其他完全一致。
| 用例 | 环境 | PR head de9d5f77d |
对照组 388be23ac |
|---|---|---|---|
| P1 | HTTP_PROXY='not a URL' |
exit 1 + Proxy environment configuration is invalid. Check HTTP_PROXY, HTTPS_PROXY, and NO_PROXY. |
exit 1 + External context startup failed. |
| P2 | HTTP_PROXY=' ' |
可诊断 | 不可诊断 |
| P4 | HTTPS_PROXY='ftp://proxy.internal:8080' |
可诊断 | 不可诊断 |
| P5 | 小写 http_proxy='not a URL' |
可诊断 | 不可诊断 |
| P6 | http://svc-account:<secret>@ bad host:3128 |
可诊断，stderr/stdout 均无凭证、用户名或主机泄漏 | 不可诊断 |
| P0/P3/P7/P8 | 无 / '' / 非法 NO_PROXY / 合法代理 |
Server 正常启动，stderr 为空 | 与 head 一致 |
head 9/9，对照组 4/9。 新增单测也不是空测：只回退 main.ts 就会让 src/main.test.ts:63 以那条不可诊断的字符串失败。另外这些常见错误写法现在也能被诊断：proxy.corp:3128（漏掉 scheme，最常见的管理员失误）、//proxy.corp:3128、http://[::1:3128。
第 2 轮验证过的代理行为没有回退：配置合法 HTTP_PROXY 指向支持 CONNECT 的 loopback 代理时，真实搜索仍然走隧道（观察到一次 CONNECT 127.0.0.1:<port>）；NO_PROXY=127.0.0.1 仍然直连绕过（无 CONNECT）。
4. 针对编译产物的协议矩阵 —— 19/19
verify7586/mcp-matrix.mjs：真实 @modelcontextprotocol/sdk 客户端 → 真实 stdio 子进程 → 真实 loopback Provider → 真实 CONNECT 代理。每个用例都断言两侧：Provider 实际收到的内容（method、path、authorization、精确 body、请求次数、socket abort），以及模型实际会看到的内容，并检查 stderr 保持为空。
- 工具面恰好只有
context_search，只有一个参数query，destructiveHint: false。 - Provider 收到
POST /v1/context/search、Bearer <token>，body 恰好是{"query":"release notes captain","limit":5}（输入为' release notes\n\tcaptain '）；模型收到 363 字符的untrusted_external_contextenvelope。 - 额外的结构化工具参数（
app_id、filters、top_k、limit、baseUrl、authorization、threshold、rerank）不会到达 Provider —— body 不变，诱饵 origin 0 次命中。 - 所有 Provider 故障都只返回
External context search failed.，Provider 请求恰好 1 次（不重试），stderr 为空：手动重定向（诱饵目标从未被访问）、声明式超大响应（content-length2 MiB）、流式超大响应（chunked 无content-length）、非法 UTF-8、非法 JSON、合法 JSON 但 envelope 非法、429、5xx。 - 非法条目被丢弃，Provider 的未知字段不会进入 envelope。
timeoutMs超时与 MCP 客户端取消都会中止 Provider 连接（Provider 侧已观察到），且不重试。- Query 边界：2000 码点会转发；2001 码点被
-32602拒绝且 Provider 从未被访问（星际平面字符同理，即 4002 个 UTF-16 单元）；全空白 query 在本地被拒为Search query must not be empty.
Mem0 V3 Adapter，真实模块 + 真实 loopback origin —— 5/5：POST /v3/memories/search/、Token <key>，即使调用方传 limit: 999，body 仍恰好为 {"query":…,"filters":{"app_id":"repository-memory"},"top_k":5,"threshold":0.1,"rerank":false}；非法结果被丢弃；两个 Adapter 的原型上只有 search；非 loopback 的 http:// origin 在构造时即被拒绝。
5. 通过真实构建的 Qwen CLI 做端到端 —— 7/7
verify7586/cli-e2e.mjs 以非交互方式驱动 packages/cli/dist/index.js，对接一个脚本化的 OpenAI 兼容端点（wire oracle），使用管理员拥有的 --mcp-config 固定入口、QWEN_CODE_SYSTEM_SETTINGS_PATH 指向受管 settings，并在 user settings 里放入一个同名诱饵 server。由于 Qwen 把 MCP 工具放在 ToolSearch 之后延迟加载，第 0 轮是一次真实的发现往返。
- 该工具出现在延迟工具清单的
#### external-context下，名称为mcp__external-context__context_search（37 字符，与permissions.allow一致），由tool_search揭示，并从下一轮起出现在tools[]中。 - 固定的 server 响应请求：Provider 收到一次
POST /v1/context/search，body 为{"query":"release cadence thursday","limit":5}；模型收到 319 字符的非可信 envelope；诱饵从未运行。 - 模型提供的语料库 selector 比预期更早被拒绝：Qwen Core 自身的 Ajv 参数校验（
packages/core/src/utils/schemaValidator.ts:247，dataVar: 'params'）以params must NOT have additional properties拒绝调用，Adapter 根本没被进入（Provider 请求数仍为 1）。这是在 Adapter 固定字段之上的额外防线。 - 不使用
--mcp-config时，user settings 中的同名 server 胜出并作出响应（DECOY-SERVER-ANSWERED，Provider 0 次请求）—— README 最核心的部署论断，现在是端到端实测而非推理。 - allow 规则确实起作用：移除后同样的调用被拒（
Qwen Code requires permission to use "mcp__external-context__context_search", but that permission was declined），Provider 从未被访问，因此非受管会话不会继承自动执行能力。 examples/managed-mcp.json中includeTools: ["context_search"]的写法正确且有效：把一个暴露两个工具的替身 server 以同名固定进来后，清单里只出现…__context_search，dangerous_write消失；不写includeTools时两个都出现。
6. 参考信息 —— 非阻塞
(a) 新消息实际会在哪里出现。 HTTP_PROXY='not a URL' 的三种放置方式：
| 组 | 放置位置 | 结果 |
|---|---|---|
| 1 | 启动器环境（管理员通常这么设） | Qwen Core 先挂：An unexpected critical error occurred: TypeError: Invalid URL，栈来自 Core 自己的 dispatcher 安装（packages/core/src/config/config.ts:2251-2258），exit 1。集成的消息根本走不到。 |
| 2 | 通过固定配置的 env 只作用于该 MCP server |
CLI 输出 Warning: MCP server(s) failed to start: external-context. … Re-run with QWEN_CODE_DEBUG=1 to see per-server reasons.；终端上看不到那条 sanitized 消息（mcp-client.ts:2181-2185 只在 debug 模式下挂 stderr 监听）。 |
| 3 | 同第 2 组，但加 --debug |
sanitized 消息确实出现在 debug 日志中 —— 按 CLI 自己的提示重跑的操作者会看到 Proxy environment configuration is invalid. Check HTTP_PROXY, HTTPS_PROXY, and NO_PROXY.，而不是 External context startup failed. |
也就是说，这个提交通过已文档化的 debug 路径以及独立运行 MCP 命令的场景确实带来了价值。第 1 组属于 Core 既有缺口（本 PR 未改动 packages/core），而且正是作者刚刚在集成内修掉的同一类问题 —— 值得单独跟进，在 Core 里做同样的 sanitized 消息处理。另外可选地在 README 加一行（"如果 server 启动失败，用 QWEN_CODE_DEBUG=1 重跑即可看到 sanitized 的启动原因"），对管理员会更完整。
(b) 格式合法但不可达的代理。 HTTP_PROXY=http://127.0.0.1:1 能正常启动；之后搜索只返回 External context search failed.，stderr 为空，Provider 0 次命中。这符合 Phase 1 不做逐请求日志的规则 —— 只是说明新诊断覆盖的是"格式非法"，而不是"格式合法但配错"。
(c) 测试文件仍在 tsc --noEmit 之外（第 2 轮第 6 项，现在有具体证据）。 使用 workspace 自己的 tsconfig.json、仅去掉 exclude 后，现有测试文件报出两个真实错误：src/main.test.ts(33,3) —— process.exitCode 的类型是 string | number | null | undefined，不能赋给局部变量的 string | number | undefined；以及 src/mcp.test.ts(69,18) —— result.content 类型为 unknown。两者都不影响运行（vitest 仅做转译，44/44 通过），eslint src 也不会报。故意注入的 const probe: number = "…" 同样对 npm run typecheck 和 eslint src 完全不可见。删掉 exclude 这一行（或加一个测试专用 tsconfig）会是一处小的加固，而本轮提交改动的正是这两个受影响文件之一。
使用的 harness
proxy-startup.mjs（9 用例 × 2 个构建）· mcp-matrix.mjs（19）· query-bounds.mjs（6）· mem0-wire.mjs（5）· cli-e2e.mjs（3 组，7）· include-tools.mjs（3）· proxy-edges.mjs（5）· operator-visibility2.mjs（3 组）。全部无 mock：编译后的 dist/、真实子进程、真实 loopback HTTP 服务、真实 CONNECT 代理、真实构建的 CLI。
|
Released in v0.21.1. |
|
|
5 participants
What this PR does
This PR adds Phase 1 of the private Direct External Context Provider integration for the narrow deployment profile where one interactive Qwen CLI process serves trusted collaborators and the external provider can issue a credential restricted to one intended corpus.
The integration exposes exactly one on-demand, retrieval-only MCP tool,
context_search({ query }). It has no hooks, automatic recall, write tools, personal memory, or runtime provider plugin system. Provider selection and all corpus selectors are fixed by administrator-controlled configuration before the MCP server starts; the model supplies only the search query.Two explicit adapters are included. Mem0 Platform V3 Search fixes
app_id, result count, threshold, and reranking in the adapter. Generic HTTP Search V1 sends only a normalized query and fixed result limit to/v1/context/search, allowing an existing knowledge base, RAG service, or enterprise search endpoint to provide the same normalized result contract.Requests use a bounded timeout without retries or caching, and client cancellation aborts the in-flight provider request. Redirects are rejected, HTTPS is required except for loopback development, provider responses are capped and strictly validated, and the final untrusted JSON envelope is bounded. Provider failures return a stable local error. Phase 1 emits no local per-request audit record and does not write queries, results, credentials, provider errors, or operation metadata to stderr.
The managed deployment pins the reviewed MCP command through an administrator-owned
--mcp-config, because a settings or project server with the same name would otherwise replace the extension manifest contribution while retaining the same permission-rule name. The managed launcher constructs the complete Qwen argument vector without passing through arbitrary caller arguments, starts from an administrator-approved environment, and supplies a launcher-specific system settings path that disables/cdand allows only the pinned search tool. The Node executable, checkout, dependency tree, provider configuration, and credential binding remain administrator-controlled and immutable for the session. The extension manifest remains available for local trusted trials but is not the managed source binding.The design documents the actual trust boundary. The provider-side credential, project, index, or corpus must enforce single-corpus access; Mem0
app_idand other client-side filters are classification rather than authorization. The Direct Profile requires the repository, its.envand.qwen/.envfiles, and same-UID code to be trusted. It does not provide DLP, credential or process isolation from the CLI user, trusted user identity, per-document ACL enforcement, non-bypassable confirmation, compliance audit, or protection from prompt injection in retrieved content. Deployments needing those controls use the governed Gateway/Orchestrator Profile in #7449.The repository lint configuration now applies the normal TypeScript and Vitest house rules to private integration workspaces, and the implementation removes the earlier single-use runtime wrapper and dead provider-binding metadata.
Why it's needed
Teams that already have repository-scoped memory or knowledge services need a low-deployment-cost way to retrieve that context from Qwen Code without changing Qwen Core or first operating the full governed gateway.
Exposing an unrestricted provider MCP server is too broad because model-controlled tenant, project, namespace, endpoint, or filter parameters can defeat the intended corpus boundary. This integration provides the minimum reviewed wrapper for trusted-team retrieval while deferring automatic recall, writes, personal identity, and policy enforcement whose authorization, privacy, latency, and lifecycle semantics require the governed profile or a separate phase.
Reviewer Test Plan
How to verify
external-contextservers in user settings and the repository MCP configuration, then start the managed profile. Confirm the command-line MCP entry wins and only the reviewedcontext_searchtool is exposed.QWEN_CODE_SYSTEM_SETTINGS_PATHonly at the managed profile settings. Confirm/cdis hidden and refused and the exact pinned search tool is allowed. Unmanaged Qwen sessions must not inherit this automatic allow rule.{"query":"normalized query","limit":5}at/v1/context/search, and Qwen receives bounded JSON underuntrusted_external_context.app_id,top_k: 5,threshold: 0.1, andrerank: false, and no add, update, or delete surface exists. Production configuration must use the fixed Mem0 API origin.External context search failed., cancellation aborts the provider request, there is no retry, and stderr remains empty of per-request data or metadata.Evidence (Before & After)
N/A. This is a non-UI private integration, tests, deployment examples, lint coverage, and design documentation.
Tested on
Environment (optional)
Node.js 22.22.3, npm 10.9.8, Qwen Code monorepo workspace. Verified 42/42 workspace tests with real loopback providers, workspace and repository build/typecheck/lint, lockfile validation, formatting, dry-run packaging, and a compiled stdio MCP fake-provider E2E with empty stderr.
Risk & Scope
permissions.askis bypassed by YOLO, and a mutable configuration path could change the corpus binding after an MCP restart; the profile is appropriate only when the provider credential is already restricted to one intended corpus and every managed input remains controlled for the session.Linked Issues
Related to #7585
Related to #7449
中文说明
本 PR 做了什么
本 PR 增加私有 Direct External Context Provider 集成的第一阶段，面向一个交互式 Qwen CLI 进程服务可信协作者，且外部 Provider 能够签发仅限一个目标语料库凭证的窄场景。
该集成只暴露一个按需、仅检索的 MCP 工具
context_search({ query })。它不包含 Hook、自动召回、写入工具、个人记忆或运行时 Provider 插件系统。Provider 选择和所有语料库 selector 都在 MCP Server 启动前由管理员控制的配置固定；模型只能提供搜索 query。本 PR 包含两个显式 Adapter。Mem0 Platform V3 Search 在 Adapter 中固定
app_id、结果数量、threshold 和 reranking。Generic HTTP Search V1 只向/v1/context/search发送归一化 query 和固定结果上限，使现有知识库、RAG 服务或企业搜索端点能够提供相同的归一化结果契约。请求使用有界超时，不重试也不缓存；客户端取消会中止正在进行的 Provider 请求。重定向会被拒绝；除 loopback 开发外必须使用 HTTPS；Provider 响应具有大小上限并经过严格校验；最终的非可信 JSON envelope 也受到边界限制。Provider 故障只返回稳定的本地错误。Phase 1 不产生本地逐请求审计记录，也不会向 stderr 写入 query、结果、凭证、Provider 错误或操作元数据。
受管部署通过管理员拥有的
--mcp-config固定经过审阅的 MCP 命令，因为同名 settings 或 project server 否则可以替换扩展 manifest 的贡献，同时继续使用相同的权限规则名。受管启动器完整构造 Qwen 参数，不透传任意调用方参数；从管理员批准的环境启动；并提供仅供该启动器使用的 system settings 路径，用于禁用/cd且只允许固定的搜索工具。Node 可执行文件、checkout、依赖树、Provider 配置和凭证绑定在会话期间都由管理员控制并保持不可变。扩展 manifest 仍可用于本地可信试用，但不是受管模式的来源绑定。设计文档明确记录真实信任边界。Provider 侧凭证、Project、Index 或 Corpus 必须强制单语料库访问；Mem0
app_id和其他客户端 filter 只是分类信息，不是鉴权。Direct Profile 要求仓库、其.env与.qwen/.env文件以及同 UID 代码可信。它不提供 DLP、对 CLI 用户的凭证或进程隔离、可信用户身份、逐文档 ACL 强制、不可绕过的确认、合规审计，也不能防止召回内容中的提示注入。需要这些控制的部署应使用 #7449 中的受管 Gateway/Orchestrator Profile。仓库 lint 配置现在会把常规 TypeScript 和 Vitest 规则应用到私有 integration workspace；实现同时删除了早期仅使用一次的 runtime wrapper 和无读取方的 Provider binding 元数据。
为什么需要
已经拥有仓库级记忆或知识服务的团队，需要一种低部署成本的方式从 Qwen Code 中检索这些上下文，同时不修改 Qwen Core，也不要求先运维完整的受管 Gateway。
直接暴露无限制的 Provider MCP Server 范围过大，因为模型可控的 tenant、project、namespace、endpoint 或 filter 参数可能破坏预期语料库边界。该集成为可信团队检索提供最小的经过审阅的封装，同时将自动召回、写入、个人身份和策略执行推迟到后续阶段或受管 Profile，因为这些能力的鉴权、隐私、延迟和生命周期语义需要单独设计。
Reviewer 测试计划
如何验证
external-contextserver，然后启动受管 Profile。确认命令行 MCP 入口胜出，并且只暴露经过审阅的context_search工具。QWEN_CODE_SYSTEM_SETTINGS_PATH指向对应 settings。确认/cd被隐藏并拒绝执行，且精确匹配的固定搜索工具被允许。非受管 Qwen 会话不得继承该自动 allow 规则。/v1/context/search收到的内容只有{"query":"normalized query","limit":5}，同时 Qwen 在untrusted_external_context下收到有界 JSON。app_id、top_k: 5、threshold: 0.1和rerank: false，并且不存在 add、update 或 delete 接口。生产配置必须使用固定的 Mem0 API origin。External context search failed.，取消会中止 Provider 请求，不发生重试，且 stderr 中不包含逐请求数据或元数据。证据（Before & After）
N/A。这是非 UI 的私有集成、测试、部署示例、lint 覆盖和设计文档。
已测试平台
环境（可选）
Node.js 22.22.3、npm 10.9.8、Qwen Code monorepo workspace。已验证使用真实 loopback Provider 的 42/42 workspace 测试、workspace 与仓库级 build/typecheck/lint、lockfile 校验、格式检查、dry-run 打包，以及编译后 stdio MCP Fake Provider E2E，且 stderr 为空。
风险与范围
permissions.ask，可变配置路径还可能在 MCP 重启后改变语料库绑定；该 Profile 仅适用于 Provider 凭证已经限制到一个目标语料库且所有受管输入在会话期间都保持受控的场景。关联 Issue
关联 #7585
关联 #7449