问题
/clear 会把 session.workingDirectory 重置回 DEFAULT_WORKING_DIR(~/Documents/ClaudeCode),完全无视 session JSON 里已持久化的值和 config.json 的配置。/clear 之后下一条消息会在错误的项目目录下新建 SDK session。
复现步骤
setup 时把工作目录设为非默认值(例如 /home/user/myproject),或之后编辑 ~/.wechat-claude-code/config.json。
- 在微信发任意消息 → session JSON 被创建并持久化,
workingDirectory 为正确值。
- 发
/status → 确认 工作目录: /home/user/myproject。
- 发
/clear。
- 再发
/status(或任意消息)→ 工作目录 已变成 ~/Documents/ClaudeCode,且新的 sdkSessionId 属于 ~-Documents-ClaudeCode 项目,而不是配置的那个。
预期 vs 实际
- 预期:
/clear 只清 sdkSessionId 和 chatHistory,保留 workingDirectory(clear() 的 currentSession 参数明显就是为此设计的)。
- 实际:
workingDirectory 被重置为 DEFAULT_WORKING_DIR(~/Documents/ClaudeCode)。
根因
Session.clear() 本来就接受当前 session 作为参数,用于把 workingDirectory 带过来:
// src/session.ts:67
function clear(accountId: string, currentSession?: Session): Session {
const session: Session = {
sdkSessionId: undefined,
workingDirectory: currentSession?.workingDirectory ?? DEFAULT_WORKING_DIR, // ← currentSession 为 undefined 时回退到默认值
...
};
}
但唯一的调用点没传它:
// src/main.ts:389
clearSession: () => sessionStore.clear(account.accountId), // ← 没传 session
所以 currentSession 永远是 undefined,workingDirectory 永远回退到 DEFAULT_WORKING_DIR。
补充:/reset(src/commands/handlers.ts:127-128)也会调用 clearSession(),但紧接着又显式赋值 DEFAULT_WORKING_DIR,所以它的行为符合设计意图,不受此 bug 影响。只有 /clear 是坏的。
另外没有任何兜底机制能挽回目录:src/main.ts:257 的启动 backfill 只在 session.workingDirectory === process.cwd()(daemon 进程的 cwd)时触发,本场景下永远不成立,所以也救不回来。
建议修复
一行改动:
--- a/src/main.ts
+++ b/src/main.ts
@@ -386,7 +386,7 @@
accountId: account.accountId,
session,
updateSession,
- clearSession: () => sessionStore.clear(account.accountId),
+ clearSession: () => sessionStore.clear(account.accountId, session),
getChatHistoryText: (limit?: number) => sessionStore.getChatHistoryText(session, limit),
text: userText,
};
改完后 /clear 就能按原设计保留 workingDirectory。我本地已验证:打上补丁后 tsc 干净编译,/clear 之后目录保持不变。
问题
/clear会把session.workingDirectory重置回DEFAULT_WORKING_DIR(~/Documents/ClaudeCode),完全无视 session JSON 里已持久化的值和config.json的配置。/clear之后下一条消息会在错误的项目目录下新建 SDK session。复现步骤
setup时把工作目录设为非默认值(例如/home/user/myproject),或之后编辑~/.wechat-claude-code/config.json。workingDirectory为正确值。/status→ 确认工作目录: /home/user/myproject。/clear。/status(或任意消息)→工作目录已变成~/Documents/ClaudeCode,且新的sdkSessionId属于~-Documents-ClaudeCode项目,而不是配置的那个。预期 vs 实际
/clear只清sdkSessionId和chatHistory,保留workingDirectory(clear()的currentSession参数明显就是为此设计的)。workingDirectory被重置为DEFAULT_WORKING_DIR(~/Documents/ClaudeCode)。根因
Session.clear()本来就接受当前 session 作为参数,用于把workingDirectory带过来:但唯一的调用点没传它:
所以
currentSession永远是undefined,workingDirectory永远回退到DEFAULT_WORKING_DIR。补充:
/reset(src/commands/handlers.ts:127-128)也会调用clearSession(),但紧接着又显式赋值DEFAULT_WORKING_DIR,所以它的行为符合设计意图,不受此 bug 影响。只有/clear是坏的。另外没有任何兜底机制能挽回目录:
src/main.ts:257的启动 backfill 只在session.workingDirectory === process.cwd()(daemon 进程的 cwd)时触发,本场景下永远不成立,所以也救不回来。建议修复
一行改动:
改完后
/clear就能按原设计保留workingDirectory。我本地已验证:打上补丁后tsc干净编译,/clear之后目录保持不变。