TapTap Maker 项目同步后 MCP cwd 与项目目录不匹配

[cindy-issue]

提交人: 用户2661
客户端版本: 0.1.69

---

问题概述

在 Windows 本地 Maker 项目中，通过插件选择项目、选择父目录并完成同步后，从该项目进入 TapTap Maker。项目绑定和同步均正常，但 Maker MCP 状态持续显示项目上下文 cwd 不匹配。

复现步骤

1. 在插件中选择一个 Maker 项目。
2. 选择项目父目录并执行同步。
3. 在同步后的项目工作区中访问 TapTap Maker。
4. 查看 Maker 状态诊断。

期望行为

MCP 服务应继承当前活动 Maker 项目目录作为工作目录，并将其识别为项目根目录。

实际行为

状态显示：

• inspected_target_dir：当前 Maker 项目目录
• maker_project_dir：当前 Maker 项目目录
• mcp_cwd：与项目目录不一致
• mcp_cwd_project_dir：未识别到 Maker 项目
• 状态：mismatch

复现频率

每次执行该流程并检查状态时均可复现。

影响

项目文件、绑定和同步本身不受影响，普通代码编辑通常正常。但依赖 MCP 默认工作目录的构建、预览、提交、远程同步或资源生成操作，可能找不到项目、执行失败，或解析到错误目录。显式指定当前项目目录时风险可降低。

已尝试

已确认项目配置、Git 根目录、Maker 工具注册和本地开发环境正常；未修改共享用户级 MCP 配置。

版本区域: CN
OS: win32 x64 (10.0.22000)
Harness: Codex
Model ID: gpt-5.6-sol
界面语言: zh-CN

[dash-s-cindy]

判断：TapTap Maker 的项目绑定与同步能力本身仍然有用户价值；当前需要处理的是同步完成后，项目目录、MCP 默认 cwd 与 Maker 项目识别结果没有形成同一条权威上下文链。该不一致足以让依赖默认工作目录的构建、预览、提交、远程同步和资源生成针对错误目录运行，因此建议继续推进。现阶段不宜直接把问题定性为 Git、项目配置或共享用户级 MCP 配置故障。

行动建议：

1. 先确认责任边界和真实输入。 由 TapTap Maker 插件提供一次脱敏诊断，至少包括插件启动/调用时收到的 session context 完整字段、Roots 列表、用户选定目标（如有）、插件最终解析的 cwd、.maker-mcp/config.json 探测路径及 project_id 判定结果。Cindy 侧同步记录同一调用的 session id、权威 workingDir、extraDirs/writableDirs 和项目绑定关系。当前仓库没有 TapTap Maker 的实际实现，也搜索不到 mcp_cwd、maker_project_dir 或 .maker-mcp 的生产代码，因此不能仅凭 Cindy 源码决定修复应落在宿主、插件还是两者的协议契约上。
2. 先拍板产品语义。 当前 Cindy 的 session_context 是 Host 铸造的可信上下文；apps/desktop/src/main/mcp-integrations/ghost.ts 在派发前会移除调用方自报的同名 session_context 字段，再注入宿主生成的值。这是防伪造设计，不应通过让插件忽略宿主字段、接受任意目录参数来绕过。buildGhostSessionContext 通过 getSessionFsSnapshot(sessionId) 读取会话持久化的 workingDir，再生成插件可见上下文。若产品语义仍是“一会话一个主 workingDir”，应让 Maker 插件使用该权威目录，并把附加目录仅作为受控引用；若产品确实允许在同一会话内选择某个附加 Maker 项目，则需要新增并持久化“活动工作区/选定 Maker 根目录”语义，或扩展 session-context 契约，由 Host 负责校验、授权和注入。
3. 不要在插件侧自行猜测多个 Roots。 仅当候选目录唯一、可访问、已绑定且通过路径归属校验时才可自动选择；多个候选、同一物理目录的不同别名、绑定状态不明、路径不存在或 junction/symlink 身份不稳定时，应返回结构化的“需要选择目标”，而不是静默选一个目录。
4. 若目录切换成为正式能力，复用 runtime 生命周期。 不能只更新 UI 或 SQLite 字段。活动目录变化后，应确保旧 runtime 不再接收新消息，再按新目录重新创建/恢复 runtime，并重新计算项目上下文、Memory、AGENTS.md 与目录授权。若现有链路已经把正确项目根目录注入给插件，而插件仍无条件覆盖它，则最小修复应落在插件字段优先级，并补充冲突输入回归；若 Host 根本没有注入选定项目，则先补上下文契约。

源码证据（快照 2a039176935c71ee0e1a6377defccbea738b034b）：

• apps/desktop/src/main/mcp-integrations/ghost.ts：buildGhostSessionContext 从 getSessionFsSnapshot(sessionId) 取得 workingDir、远程标记和只读状态；派发前剥除调用方的 session_context，随后仅注入 Host 铸造值。
• apps/desktop/src/main/localDb/schema.ts：sessions 表有 workingDir、workspaceKind、extraDirs、writableDirs，没有“活动工作区”或“当前选中 Root”字段。注释也明确 workingDir 是项目/对话的主运行目录，extraDirs 与 writableDirs 是附加授权目录。
• apps/desktop/src/main/localDb/ipc/sessions.ts：getSessionFsSnapshot 只读取会话行的 workingDir、权限、计划模式和远程 host；现有快照接口没有返回活动 Root 或 Maker 绑定信息。
• packages/lizi-mcps/src/__tests__/sessionContext.test.ts：覆盖的是单一 workingDir 的静态/动态会话上下文解析，以及无上下文时 fail-closed；没有覆盖多 Roots、用户选中目录或 Maker 绑定关系。

风险与验证：

• 若仅改插件接受调用方目录，可能绕过 Host 的路径授权和防伪造边界，不建议作为方案。
• 若新增活动目录语义，需要明确它是否改变 Agent 的实际 cwd、项目 Memory、项目知识和可写范围；这些必须一起切换，不能只改变状态展示。
• 最小验证矩阵应覆盖：仅会话目录；会话目录 + 唯一已绑定 Maker 根目录；多个 Maker 根目录；重新附加/切换/刷新后再次调用；显式目录与 Host 上下文冲突；Windows 盘符大小写、分隔符、junction/symlink、目录不存在及绑定缺失。每种情形都应同时比较 mcp_cwd、项目目录、project_id、配置探测路径，以及状态、构建、预览、提交的实际目标。

相关记录：

• #3680：同一类多工作区 Maker cwd 不一致；讨论已核实 session_context 当前来自持久化主 workingDir，而 UI 的活动工作区未落库，直接支持本 Issue 的契约边界判断。
• #3026：尝试在会话移动到项目后关闭 Pi/Codex 旧 handle，让下一次发送按新 workingDir lazy-create。该 PR 未合入，且讨论中仍有结构性/流程问题；可作为 runtime 切换生命周期参考，不能作为本 Issue 已修复证据。

在获得插件运行诊断和维护者对“主 workingDir vs 活动 Maker 工作区”语义的确认前，最可靠的推进结论是：问题值得处理，第一步是补齐宿主—插件上下文事实和契约决策，而不是先实现自动猜目录或放宽显式 cwd。

[fico-hub]

认领:先定界 MCP cwd 装配发生在宿主侧还是插件内部——宿主侧有确定性缺口就直接提 PR,插件内部则回贴划界。

[fico-hub]

定界结论(释放认领):这与 #3680 同根——宿主把 MCP/插件运行时的 cwd 恒绑定到会话工作目录(sessions.workingDir),不存在「插件内选定的活动项目目录」这一状态;你诊断里 mcp_cwd ≠ maker_project_dir 正是该缺口的读数(inspected_target_dir/maker_project_dir 是插件自己解析的,mcp_cwd 是宿主注入的会话目录)。

#3680 的取证已确认:两条修复路径(给 session_context 增加活动工作区态,或让插件声明 cwd 覆盖)都要动插件基座的能力 slot 契约,按仓规走白名单确认门 + 需要维护者拍产品方向,结论已在该 issue 回贴等待拍板。建议本 issue 与 #3680 合并跟踪;临时缓解:让 Agent 显式以项目目录绝对路径调用构建/预览类操作(你「影响」一节里也验证了显式指定可降风险)。