Claude Code配置DeepSeek后claude-mem插件“No previous sessions found for this project“的问题

claude-mem 默认使用系统钥匙串中的 OAuth Token 向 Anthropic API 鉴权。当你把 API 底座换成 DeepSeek 后，这个鉴权方式会直接失效，SDK 对每一次记忆生成请求都返回Not logged in · Please run /login，然后被 parser 当作"空响应"静默丢弃——表面上一切正常，实际一条记忆都没落库。解决方案就是把鉴权从 OAuth token 切换为 API Key，并将 Base URL 指向 DeepSeek 的 Anthropic 兼容端点。

1. 背景

claude-mem 是 Claude Code 生态中最流行的记忆插件之一，它会在每次会话中自动捕捉你的操作上下文、生成结构化记忆（observation），并在后续会话中将这些记忆注入 system prompt，实现"跨会话记忆"。

我日常使用 DeepSeek v4 系列模型作为 Claude Code 的后端，API 底座是https://api.deepseek.com/anthropic（DeepSeek 提供的 Anthropic Messages API 兼容端点）。在安装 claude-mem 之后，插件本身的安装和 MCP server 启动一切正常，/mem-search技能也能成功加载——但无论经过多少次会话，dashboard 中始终看不到任何新产生的记忆，在设置面板中发现了No previous sessions found for this project yet.提示。

这篇文章记录了我从发现问题到最终修复的完整过程。

2. 故障现象

最令人困惑的是：插件没有任何报错信息暴露给用户。你在 Claude Code 中正常使用，对话一切流畅，只是记忆永远不产生。

3. 排查过程

3.1 确认 worker 是否存活

第一步检查 worker 进程和其 dashboard：

# 检查 worker PID 文件Get-Content~/.claude-mem/worker.pid# → {"pid":9908,"port":37777,"startedAt":"2026-05-21T07:23:48.616Z"}# 检查进程是否存在Get-Process-Id 9908

Dashboard 在http://127.0.0.1:37777正常渲染，说明 worker 本身没有问题。

3.2 检查 worker 日志——发现关键线索

日志位置：~/.claude-mem/logs/claude-mem-YYYY-MM-DD.log

# 每次 SDK 调用的返回都是完全相同的一句话（33 个字符）： [SDK] ← Response received (33 chars) Not logged in · Please run /login # Parser 收到非 XML 响应后直接丢弃： [PARSER] SDK returned non-XML/empty response — ignoring queued batch

这个错误重复了上百次——每一个 observation 的生成请求都以Not logged in被拒绝，而 parser 静默丢弃了这些非 XML 响应，导致用户层面完全无感知。

3.3 定位根因：鉴权方式不兼容

进一步查看 SDK 启动日志：

# 修复前（session-17/18）： [SDK] Starting SDK query { authMethod=Claude Code OAuth token (read from system keychain at spawn) } # → "Not logged in · Please run /login"

关键发现：claude-mem 默认使用“Claude Code OAuth token”鉴权方式——它从系统钥匙串中读取 Claude Code 的 OAuth token，然后向 Anthropic API 发起请求。这个 token 自然只在 Anthropic 的官方 API 上有效。当你把ANTHROPIC_BASE_URL指向 DeepSeek 后，DeepSeek 的 API 网关根本不认识这个 OAuth token，直接返回Not logged in。

# 修复后（session-19）： [SDK] Starting SDK query { authMethod=Gateway auth token (from ~/.claude-mem/.env) } # → observations 正常生成，Response 长度从 33 chars 跃升至 750~2687 chars

4. 解决方案

核心思路：将鉴权方式从 OAuth Token 切换为 API Key，并确保.env文件同时存在（claude-mem 的 SDK spawn 子进程需要从.env读取环境变量）。

4.1 修改~/.claude-mem/settings.json

{"CLAUDE_MEM_PROVIDER":"claude","CLAUDE_MEM_MODEL":"deepseek-v4-flash","CLAUDE_MEM_CLAUDE_AUTH_METHOD":"api-key","ANTHROPIC_AUTH_TOKEN":"sk-你的DeepSeek-API-Key","ANTHROPIC_BASE_URL":"https://api.deepseek.com/anthropic","ANTHROPIC_API_KEY":"","CLAUDE_MEM_OPENROUTER_API_KEY":"","CLAUDE_MEM_OPENROUTER_MODEL":""}

每个字段的意义：

4.2 创建~/.claude-mem/.env

这是必须步骤——claude-mem 在 spawn 子进程调用 Claude SDK 时，会从.env文件读取环境变量。仅配置 settings.json 而缺少.env会导致子进程仍然回退到 OAuth token 鉴权。

# ~/.claude-mem/.envANTHROPIC_AUTH_TOKEN=sk-你的DeepSeek-API-KeyANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic

4.3 重启 worker

配置修改后，必须杀掉旧 worker 并重新启动：

# 1. 找到并杀掉旧 workerGet-Content~/.claude-mem/worker.pid# 获取 PIDStop-Process-Id <PID>-Force# 2. 清理 PID 文件（可选，worker 会自动处理 stale PID）Remove-Item~/.claude-mem/worker.pid# 3. 重新触发 Claude Code 会话——worker 会自动启动

新的 Claude Code 会话启动后，worker 会自动 spawn。你可以在日志中验证：

# 期望看到的日志行： [SDK] Starting SDK query { authMethod=Gateway auth token (from ~/.claude-mem/.env) } # ↑ "Gateway auth token" 说明已切换到 .env 中的 API Key

4.4 验证修复

# 检查日志中的 SDK 返回长度——应该远超 33 charsSelect-String-Path ~/.claude-mem/logs/claude-mem-*.log-Pattern"Response received"# 修复前：全部是 "(33 chars)"# 修复后：出现 "(750 chars)"、"(1203 chars)"、"(2687 chars)" 等# 打开 dashboard 确认 observation 已落库Start-Process"http://127.0.0.1:37777"

5. 为什么这个 bug 如此隐蔽？

整个故障链路中有三个"静默失败"层叠在一起：

OAuth Token → DeepSeek API → SDK 返回 "Not logged in" (纯文本，非 XML) → Parser 判定为 "non-XML/empty response" → 静默丢弃，不报错，不告警 → 用户界面无任何异常提示

claude-mem 的 parser 设计假设 SDK 返回的一定是合法 XML。当 API 返回纯文本错误消息时，parser 直接丢弃该批次，不会向上游报告错误。这是一个合理的"脏数据防御"策略，但在鉴权失败场景下会导致问题完全不可见。

6. 延伸：模型选择建议

对于记忆生成（observation generation）这个任务：

实际测试中，deepseek-v4-flash每次 observation 生成约 500-2000 个 token（包含 XML 标记），延迟在 1-3 秒以内，效果完全满足需求。