claude-mem ChromaDB 核心缺陷根因修复v10.3.0 uvx 迁移后的五类问题与代码级修复方案【免费下载链接】claude-memPersistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode More项目地址: https://gitcode.com/GitHub_Trending/cl/claude-mem本文基于仓库中 2026-02-23 的 Issue Triage playbookTRIAGE-01-ChromaDB-Core-Fixes.md系统讲解 claude-mem 从 JS Chroma 绑定迁移到 Python chroma-mcp经 uvx 拉起后出现的最大缺陷簇约 25 个 issue的根因定位与修复实现。读完后你将掌握Python 版本锁定--pythonpinning、Windows 路径归一化、Chroma 一键降级开关、元数据清洗与批量容错、MCP 传输层防御性处理这五类修复的完整实现原理以及对应配置项的取值与默认值能够排查和验证自己环境中的语义搜索故障。背景v10.3.0 迁移是单一最大 bug 来源原 playbook 开宗明义v10.3.0 将向量检索栈从 JS Chroma 绑定切换为通过 uvx 拉起的 Python chroma-mcp 子进程这一迁移是最大的 bug 来源。playbook 归纳的根因链条为关键根因buildCommandArgs()从不读取CLAUDE_MEM_PYTHON_VERSION配置尽管该配置已存在于 SettingsDefaultsManager 中。没有--python锁定uvx 会随手挑选系统上任何可用的 Python而 Python 3.14 会破坏 pydantic 依赖链次因一Windows 反斜杠路径会击穿 chromadb 的 Rust 绑定报Access Denied (OS error 5)次因二不想用 Chroma 的用户没有任何禁用开关。playbook 声称覆盖的 issue 包括 #1196、#1206、#1208Python 锁定、#1199Windows 路径、#707禁用 Chroma、#1183、#1188元数据错误、#1162Rust panic、#642JSON 解析错误、#1182SSL。以下逐项对照当前仓库源码说明根因验证结论与修复落地形态。修复一Python 版本锁定--pythonpinning根因验证playbook 判定这是CONFIRMED BUGbuildCommandArgs()构造 uvx 参数时从不读取CLAUDE_MEM_PYTHON_VERSION该配置在 SettingsDefaultsManager.ts 中默认值为3.13此前却从未被消费。当前实现在 ChromaMcpManager.ts 的buildCommandArgs()中修复后的取值链为“环境变量 用户配置 硬编码兜底”const pythonVersion process.env.CLAUDE_MEM_PYTHON_VERSION || settings.CLAUDE_MEM_PYTHON_VERSION || 3.13;随后buildLauncherPrefix()ChromaMcpManager.ts#L573-L581把版本拼进 uvx 启动前缀且 local 与 remote 两种模式共用该前缀private static buildLauncherPrefix(pythonVersion: string): string[] { const depOverrideFlags CHROMA_MCP_DEP_OVERRIDES.flatMap(spec [--with, spec]); return [ --python, pythonVersion, ...depOverrideFlags, --from, chroma-mcp${CHROMA_MCP_PINNED_VERSION}, chroma-mcp, ]; }由此实际拼出的 uvx 命令行local 模式等价于uvx --python 3.13 --with onnxruntime1.20 --with protobuf7 \ --from chroma-mcp0.2.6 chroma-mcp \ --client-type persistent --data-dir chroma-data-dir 正斜杠路径值得注意的两点源码细节版本同时双锁定除 Python 外chroma-mcp 本体也被钉死在CHROMA_MCP_PINNED_VERSION 0.2.6ChromaMcpManager.ts#L42避免 uvx 静默升级 chroma-mcp 引入行为漂移依赖地板覆盖CHROMA_MCP_DEP_OVERRIDESChromaMcpManager.ts#L59-L62强制onnxruntime1.20旧版无法解析 all-MiniLM-L6-v2 的 pytorch-2.0 IR报INVALID_PROTOBUF和protobuf77.x 的严格检查会拒绝 opentelemetry 的旧生成桩import chromadb 即抛错。这两条 pin 是运行时uvx --with注入不改上游 chroma-mcp。修复二Windows 反斜杠路径归一化根因验证playbook 判定这是CONFIRMED BUGChroma 数据目录由path.join()生成Windows 上形如C:\Users\...\.claude-mem\chromachromadb 的 Rust 绑定遇到反斜杠路径会抛Access Denied (OS error 5)对应 issue #1199。当前实现修复严格限定在 uvx 参数层面不动常量本身——--data-dir参数在传给 uvx 前做一次正斜杠替换ChromaMcpManager.ts#L422-L426return [ ...launcherPrefix, --client-type, persistent, --data-dir, localChromaDataDir.replace(/\\/g, /) ];从源码结构看数据目录本体来自paths.chroma()ChromaMcpManager.ts#L379-L383仅当CLAUDE_MEM_CHROMA_MODE为local默认时启用持久化目录remote 模式传null不走该分支。playbook 特别强调这个替换“只应用于传给 uvx 的--data-dir参数而非常量本身”因为 Node 侧fs操作在 Windows 上使用反斜杠路径是完全合法的问题只出在 Python 侧。修复三CLAUDE_MEM_CHROMA_ENABLED一键降级为 SQLite-only根因验证playbook 对应 issue #707此前无法完全禁用 Chroma。修复方案是新增CLAUDE_MEM_CHROMA_ENABLED配置默认true设为false时全链路走 SQLite 检索。当前实现四处协作配置注册SettingsDefaultsManager.ts#L189 声明默认值接口字段在 第 73 行worker 启动跳过管理器worker-service.ts#L478-L484 中禁用时不再实例化ChromaMcpManager并记录日志Chroma disabled via CLAUDE_MEM_CHROMA_ENABLEDfalse, skipping ChromaMcpManager数据库层返回 nullDatabaseManager.ts#L31-L36 中禁用时chromaSync保持nullgetChromaSync()返回 null 而非抛错搜索编排优雅降级SearchOrchestrator.ts#L30-L41 的构造器接受ChromaSync | null为 null 时不构建 Chroma 策略executeWithFallback() 直接返回 SQLite 结果strategy: sqlite。SearchManager.ts#L41 同步改为接受ChromaSync | null并对所有调用点做判空。playbook 还要求禁用时跳过全量回填worker-service.ts#L646-L650 中ChromaSync.backfillAllProjects(...)被包在if (this.chromaMcpManager)条件里禁用状态下该对象为 undefined回填自然不发生。此外降级状态对外可见HTTP 端点 ChromaRoutes.ts 的/api/chroma/status在禁用时返回status: disabled并附说明Chroma is disabled via CLAUDE_MEM_CHROMA_ENABLEDfalsedependency-preflight.ts#L163 的启动前依赖检查也以! false判定是否检查 uvx 可用性避免禁用用户被 uvx 缺失误报警告。修复四元数据清洗与批量写入容错根因验证playbook 对元数据问题issue #1183、#1188的判定是“LIKELY STILL AN ISSUE”addDocuments()经 MCP 把元数据传给 chroma-mcp一旦值出现 null/undefined/嵌套就会被拒。虽然ChromaDocument接口把元数据约束为Recordstring, string | numberChromaSync.ts#L41-L45但回填路径读的是原始 SQLite 行merged_into_project等字段可能为 null见 formatObservationDocs() 中baseMetadata的类型Recordstring, string | number | null。当前实现addDocuments()ChromaSync.ts#L301-L429落地了 playbook 指定的两层防护1) 发送前清洗——每个批次在chroma_add_documents调用前过滤掉 null/undefined/空字符串值const cleanMetadatas batch.map(d Object.fromEntries( Object.entries(d.metadata).filter(([_, v]) v ! null v ! undefined v ! ) ) );2) 逐批 try/catch单批失败不中断回填——批内异常被记录后循环继续同时针对already exist冲突做了比 playbook 更完整的调和由于chroma_add_documents只要批内有任一并存 ID 就拒绝整批而chroma_update_documents又会静默忽略不存在的 ID实现采用“先chroma_get_documents查存量 → 存量走 update、新增走 add”的分裂写入ChromaSync.ts#L347-L405注释中还解释了为何不用 deleteaddHNSW 删除是软删除deleteadd 循环会让link_lists.bin中的旧图节点无限堆积。另一个与元数据健壮性直接相关的水位语义addDocuments()返回实际写入条数而非无脑成功syncObservation() 仅在written documents.length时才推进水位ChromaSyncState.bump部分失败会留待下次启动时由 backfill 重新补齐避免“被跳过未同步记录”的数据丢失。修复五callTool()传输层防御Rust panic 场景根因验证playbook 对应 issue #1162callTool()原实现只对result.isError抛错不捕获底层传输错误chroma-mcp 子进程若 panic例如 chromadb v1.1.1 的 HNSW 索引损坏await this.client!.callTool(...)会直接抛未处理异常。当前实现callToolUnqueued() 在 playbook 要求的 try/catch connected false基础上进一步演进为一次自动重连重试捕获传输层异常后先确认连接代际未被 shutdown 打断调用disposeCurrentSubprocess()对整个子进程树uvx/uv/python/chroma-mcp做 tree-kill——注释引用 #2313 说明MCP SDK 的transport.close()只结束直接子进程Linux 上孙进程会重新挂给 init 并累积必须先树杀再重连ensureConnected()重建连接后原调用重试一次重试仍失败才置connected false并抛错工具返回值的JSON.parse同样被 try/catch 包裹非 JSON 响应记 debug 日志并返回null而不是崩溃ChromaMcpManager.ts#L824-L834这对应 playbook 列出的 #642JSON parse error。playbook 明确“不要加熔断器或连续失败计数保持简单”当前实现也未引入熔断器仅有一个 10 秒的重连退避RECONNECT_BACKOFF_MS 10_000ChromaMcpManager.ts#L35。SSL 默认值验证结论为“无需修复”playbook 对 SSLissue #1182的结论是ALREADY CORRECTCLAUDE_MEM_CHROMA_SSL默认falseSettingsDefaultsManager.ts#L193remote 模式仅在配置为真时追加--ssl true。当前代码保持该行为且--ssl参数现在显式传true/false字符串ChromaMcpManager.ts#L405只有用户显式覆写时才启用 TLS。Chroma 相关配置项速查结合 SettingsDefaultsManager.ts#L189-L197 的默认值与源码解析逻辑全部 Chroma 配置项如下配置项默认值说明CLAUDE_MEM_CHROMA_ENABLEDtrue设为false完全禁用 Chroma全链路 SQLite-only 检索CLAUDE_MEM_CHROMA_MODElocallocal用 uvx 拉起持久化 chroma-mcpremote连已有服务CLAUDE_MEM_PYTHON_VERSION3.13uvx--python锁定值环境变量同名项优先级更高CLAUDE_MEM_CHROMA_HOST/PORT127.0.0.1/8000仅 remote 模式生效CLAUDE_MEM_CHROMA_SSLfalse仅 remote 模式映射--ssl参数CLAUDE_MEM_CHROMA_TENANT/DATABASEdefault_tenant/default_database与默认值相同则不追加参数CLAUDE_MEM_CHROMA_API_KEY空非空时追加--api-keyCLAUDE_MEM_CHROMA_PREWARM_TIMEOUT_MS120000首连前 uvx 预热线程超时合法区间 1600000 毫秒预热线程本身值得了解连接前会先用相同参数执行chroma-mcp --helpprewarmChromaMcpChromaMcpManager.ts#L641-L752强制 uvx 完成环境构建把“首连慢/失败”从 MCP 握手阶段提前到可观测的独立步骤失败会记录输出尾部并抛ChromaUnavailableError而非让 30 秒的 MCP 连接超时报一个模糊错误。验证基线playbook 的收尾任务记录了验证标准npm test全量跑通记录为 932 个测试通过、21 个与本修复无关的既有失败npm run build-and-sync构建成功。当前仓库中与该主题相关的回归测试可参考 tests/integration/chroma-vector-sync.test.ts、tests/integration/chroma-windows-lifecycle.test.ts、tests/services/sync/ 与 tests/shared/uvx-env-sanitization.test.ts覆盖向量同步、Windows 生命周期与 uvx 环境清洗等面。排查建议语义搜索异常时先看~/.claude-mem下的日志中CHROMA_MCP前缀条目预热线程会打印完整 uvx 命令与参数再核对CLAUDE_MEM_PYTHON_VERSION是否被环境意外覆写确认是否可用也可调用 worker 的/api/chroma/status端点禁用态会返回明确的disabled状态。【免费下载链接】claude-memPersistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode More项目地址: https://gitcode.com/GitHub_Trending/cl/claude-mem创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
claude-mem ChromaDB 核心缺陷根因修复v10.3.0 uvx 迁移后的五类问题与代码级修复方案【免费下载链接】claude-memPersistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode More项目地址: https://gitcode.com/GitHub_Trending/cl/claude-mem本文基于仓库中 2026-02-23 的 Issue Triage playbookTRIAGE-01-ChromaDB-Core-Fixes.md系统讲解 claude-mem 从 JS Chroma 绑定迁移到 Python chroma-mcp经 uvx 拉起后出现的最大缺陷簇约 25 个 issue的根因定位与修复实现。读完后你将掌握Python 版本锁定--pythonpinning、Windows 路径归一化、Chroma 一键降级开关、元数据清洗与批量容错、MCP 传输层防御性处理这五类修复的完整实现原理以及对应配置项的取值与默认值能够排查和验证自己环境中的语义搜索故障。背景v10.3.0 迁移是单一最大 bug 来源原 playbook 开宗明义v10.3.0 将向量检索栈从 JS Chroma 绑定切换为通过 uvx 拉起的 Python chroma-mcp 子进程这一迁移是最大的 bug 来源。playbook 归纳的根因链条为关键根因buildCommandArgs()从不读取CLAUDE_MEM_PYTHON_VERSION配置尽管该配置已存在于 SettingsDefaultsManager 中。没有--python锁定uvx 会随手挑选系统上任何可用的 Python而 Python 3.14 会破坏 pydantic 依赖链次因一Windows 反斜杠路径会击穿 chromadb 的 Rust 绑定报Access Denied (OS error 5)次因二不想用 Chroma 的用户没有任何禁用开关。playbook 声称覆盖的 issue 包括 #1196、#1206、#1208Python 锁定、#1199Windows 路径、#707禁用 Chroma、#1183、#1188元数据错误、#1162Rust panic、#642JSON 解析错误、#1182SSL。以下逐项对照当前仓库源码说明根因验证结论与修复落地形态。修复一Python 版本锁定--pythonpinning根因验证playbook 判定这是CONFIRMED BUGbuildCommandArgs()构造 uvx 参数时从不读取CLAUDE_MEM_PYTHON_VERSION该配置在 SettingsDefaultsManager.ts 中默认值为3.13此前却从未被消费。当前实现在 ChromaMcpManager.ts 的buildCommandArgs()中修复后的取值链为“环境变量 用户配置 硬编码兜底”const pythonVersion process.env.CLAUDE_MEM_PYTHON_VERSION || settings.CLAUDE_MEM_PYTHON_VERSION || 3.13;随后buildLauncherPrefix()ChromaMcpManager.ts#L573-L581把版本拼进 uvx 启动前缀且 local 与 remote 两种模式共用该前缀private static buildLauncherPrefix(pythonVersion: string): string[] { const depOverrideFlags CHROMA_MCP_DEP_OVERRIDES.flatMap(spec [--with, spec]); return [ --python, pythonVersion, ...depOverrideFlags, --from, chroma-mcp${CHROMA_MCP_PINNED_VERSION}, chroma-mcp, ]; }由此实际拼出的 uvx 命令行local 模式等价于uvx --python 3.13 --with onnxruntime1.20 --with protobuf7 \ --from chroma-mcp0.2.6 chroma-mcp \ --client-type persistent --data-dir chroma-data-dir 正斜杠路径值得注意的两点源码细节版本同时双锁定除 Python 外chroma-mcp 本体也被钉死在CHROMA_MCP_PINNED_VERSION 0.2.6ChromaMcpManager.ts#L42避免 uvx 静默升级 chroma-mcp 引入行为漂移依赖地板覆盖CHROMA_MCP_DEP_OVERRIDESChromaMcpManager.ts#L59-L62强制onnxruntime1.20旧版无法解析 all-MiniLM-L6-v2 的 pytorch-2.0 IR报INVALID_PROTOBUF和protobuf77.x 的严格检查会拒绝 opentelemetry 的旧生成桩import chromadb 即抛错。这两条 pin 是运行时uvx --with注入不改上游 chroma-mcp。修复二Windows 反斜杠路径归一化根因验证playbook 判定这是CONFIRMED BUGChroma 数据目录由path.join()生成Windows 上形如C:\Users\...\.claude-mem\chromachromadb 的 Rust 绑定遇到反斜杠路径会抛Access Denied (OS error 5)对应 issue #1199。当前实现修复严格限定在 uvx 参数层面不动常量本身——--data-dir参数在传给 uvx 前做一次正斜杠替换ChromaMcpManager.ts#L422-L426return [ ...launcherPrefix, --client-type, persistent, --data-dir, localChromaDataDir.replace(/\\/g, /) ];从源码结构看数据目录本体来自paths.chroma()ChromaMcpManager.ts#L379-L383仅当CLAUDE_MEM_CHROMA_MODE为local默认时启用持久化目录remote 模式传null不走该分支。playbook 特别强调这个替换“只应用于传给 uvx 的--data-dir参数而非常量本身”因为 Node 侧fs操作在 Windows 上使用反斜杠路径是完全合法的问题只出在 Python 侧。修复三CLAUDE_MEM_CHROMA_ENABLED一键降级为 SQLite-only根因验证playbook 对应 issue #707此前无法完全禁用 Chroma。修复方案是新增CLAUDE_MEM_CHROMA_ENABLED配置默认true设为false时全链路走 SQLite 检索。当前实现四处协作配置注册SettingsDefaultsManager.ts#L189 声明默认值接口字段在 第 73 行worker 启动跳过管理器worker-service.ts#L478-L484 中禁用时不再实例化ChromaMcpManager并记录日志Chroma disabled via CLAUDE_MEM_CHROMA_ENABLEDfalse, skipping ChromaMcpManager数据库层返回 nullDatabaseManager.ts#L31-L36 中禁用时chromaSync保持nullgetChromaSync()返回 null 而非抛错搜索编排优雅降级SearchOrchestrator.ts#L30-L41 的构造器接受ChromaSync | null为 null 时不构建 Chroma 策略executeWithFallback() 直接返回 SQLite 结果strategy: sqlite。SearchManager.ts#L41 同步改为接受ChromaSync | null并对所有调用点做判空。playbook 还要求禁用时跳过全量回填worker-service.ts#L646-L650 中ChromaSync.backfillAllProjects(...)被包在if (this.chromaMcpManager)条件里禁用状态下该对象为 undefined回填自然不发生。此外降级状态对外可见HTTP 端点 ChromaRoutes.ts 的/api/chroma/status在禁用时返回status: disabled并附说明Chroma is disabled via CLAUDE_MEM_CHROMA_ENABLEDfalsedependency-preflight.ts#L163 的启动前依赖检查也以! false判定是否检查 uvx 可用性避免禁用用户被 uvx 缺失误报警告。修复四元数据清洗与批量写入容错根因验证playbook 对元数据问题issue #1183、#1188的判定是“LIKELY STILL AN ISSUE”addDocuments()经 MCP 把元数据传给 chroma-mcp一旦值出现 null/undefined/嵌套就会被拒。虽然ChromaDocument接口把元数据约束为Recordstring, string | numberChromaSync.ts#L41-L45但回填路径读的是原始 SQLite 行merged_into_project等字段可能为 null见 formatObservationDocs() 中baseMetadata的类型Recordstring, string | number | null。当前实现addDocuments()ChromaSync.ts#L301-L429落地了 playbook 指定的两层防护1) 发送前清洗——每个批次在chroma_add_documents调用前过滤掉 null/undefined/空字符串值const cleanMetadatas batch.map(d Object.fromEntries( Object.entries(d.metadata).filter(([_, v]) v ! null v ! undefined v ! ) ) );2) 逐批 try/catch单批失败不中断回填——批内异常被记录后循环继续同时针对already exist冲突做了比 playbook 更完整的调和由于chroma_add_documents只要批内有任一并存 ID 就拒绝整批而chroma_update_documents又会静默忽略不存在的 ID实现采用“先chroma_get_documents查存量 → 存量走 update、新增走 add”的分裂写入ChromaSync.ts#L347-L405注释中还解释了为何不用 deleteaddHNSW 删除是软删除deleteadd 循环会让link_lists.bin中的旧图节点无限堆积。另一个与元数据健壮性直接相关的水位语义addDocuments()返回实际写入条数而非无脑成功syncObservation() 仅在written documents.length时才推进水位ChromaSyncState.bump部分失败会留待下次启动时由 backfill 重新补齐避免“被跳过未同步记录”的数据丢失。修复五callTool()传输层防御Rust panic 场景根因验证playbook 对应 issue #1162callTool()原实现只对result.isError抛错不捕获底层传输错误chroma-mcp 子进程若 panic例如 chromadb v1.1.1 的 HNSW 索引损坏await this.client!.callTool(...)会直接抛未处理异常。当前实现callToolUnqueued() 在 playbook 要求的 try/catch connected false基础上进一步演进为一次自动重连重试捕获传输层异常后先确认连接代际未被 shutdown 打断调用disposeCurrentSubprocess()对整个子进程树uvx/uv/python/chroma-mcp做 tree-kill——注释引用 #2313 说明MCP SDK 的transport.close()只结束直接子进程Linux 上孙进程会重新挂给 init 并累积必须先树杀再重连ensureConnected()重建连接后原调用重试一次重试仍失败才置connected false并抛错工具返回值的JSON.parse同样被 try/catch 包裹非 JSON 响应记 debug 日志并返回null而不是崩溃ChromaMcpManager.ts#L824-L834这对应 playbook 列出的 #642JSON parse error。playbook 明确“不要加熔断器或连续失败计数保持简单”当前实现也未引入熔断器仅有一个 10 秒的重连退避RECONNECT_BACKOFF_MS 10_000ChromaMcpManager.ts#L35。SSL 默认值验证结论为“无需修复”playbook 对 SSLissue #1182的结论是ALREADY CORRECTCLAUDE_MEM_CHROMA_SSL默认falseSettingsDefaultsManager.ts#L193remote 模式仅在配置为真时追加--ssl true。当前代码保持该行为且--ssl参数现在显式传true/false字符串ChromaMcpManager.ts#L405只有用户显式覆写时才启用 TLS。Chroma 相关配置项速查结合 SettingsDefaultsManager.ts#L189-L197 的默认值与源码解析逻辑全部 Chroma 配置项如下配置项默认值说明CLAUDE_MEM_CHROMA_ENABLEDtrue设为false完全禁用 Chroma全链路 SQLite-only 检索CLAUDE_MEM_CHROMA_MODElocallocal用 uvx 拉起持久化 chroma-mcpremote连已有服务CLAUDE_MEM_PYTHON_VERSION3.13uvx--python锁定值环境变量同名项优先级更高CLAUDE_MEM_CHROMA_HOST/PORT127.0.0.1/8000仅 remote 模式生效CLAUDE_MEM_CHROMA_SSLfalse仅 remote 模式映射--ssl参数CLAUDE_MEM_CHROMA_TENANT/DATABASEdefault_tenant/default_database与默认值相同则不追加参数CLAUDE_MEM_CHROMA_API_KEY空非空时追加--api-keyCLAUDE_MEM_CHROMA_PREWARM_TIMEOUT_MS120000首连前 uvx 预热线程超时合法区间 1600000 毫秒预热线程本身值得了解连接前会先用相同参数执行chroma-mcp --helpprewarmChromaMcpChromaMcpManager.ts#L641-L752强制 uvx 完成环境构建把“首连慢/失败”从 MCP 握手阶段提前到可观测的独立步骤失败会记录输出尾部并抛ChromaUnavailableError而非让 30 秒的 MCP 连接超时报一个模糊错误。验证基线playbook 的收尾任务记录了验证标准npm test全量跑通记录为 932 个测试通过、21 个与本修复无关的既有失败npm run build-and-sync构建成功。当前仓库中与该主题相关的回归测试可参考 tests/integration/chroma-vector-sync.test.ts、tests/integration/chroma-windows-lifecycle.test.ts、tests/services/sync/ 与 tests/shared/uvx-env-sanitization.test.ts覆盖向量同步、Windows 生命周期与 uvx 环境清洗等面。排查建议语义搜索异常时先看~/.claude-mem下的日志中CHROMA_MCP前缀条目预热线程会打印完整 uvx 命令与参数再核对CLAUDE_MEM_PYTHON_VERSION是否被环境意外覆写确认是否可用也可调用 worker 的/api/chroma/status端点禁用态会返回明确的disabled状态。【免费下载链接】claude-memPersistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode More项目地址: https://gitcode.com/GitHub_Trending/cl/claude-mem创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
