官方提 issue 的确认卡片依赖默认未安装的 GitHub 插件，首次使用无引导

[gpgpgpgp2022]

客户端版本: 0.1.33
反馈类型: feature

---

使用场景

想给 Cindy 官方提交 bug / 功能建议。用户使用官方内置的 /issue 指令发起反馈，agent 会按流程用 cindy_helper 的 submit_github_issue 提交，工具说明承诺「调用后会在 App 内弹出系统确认卡片，用户可以编辑标题/正文并确认或取消」。

诉求

反馈入口应开箱即用；缺依赖时应给出明确引导，而不是让用户和 agent 在黑暗中各自摸索。

建议方案

1. 调用 submit_github_issue 前检测 GitHub 插件是否启用：未启用时返回可操作提示（如「请先在设置中启用 GitHub 插件并绑定账号」+ 入口路径），而不是笼统的「could not verify this session's tool policy」。
2. /issue 指令与官方文档补充前置条件：反馈卡片需要先安装/启用 GitHub 插件并绑定账号。
3. 若走平台代提交降级，应明确告知身份差异（平台身份 vs 本人 GitHub），避免误导。

实际经历（复现参考）

通过官方 /issue 指令真实提交 #1870 时的过程，供复现：

1. 按 /issue 指令让 agent 用 cindy_helper 提交，但该工具在当前会话里根本没有暴露；直连 MCP 端点也返回「could not verify this session's tool policy. Start a new session and try again.」——没有任何线索提示根因是 GitHub 插件未启用。
2. 一番折腾（翻会话 rollout 文件找到线程 ID、手动带 _meta.threadId 才打通 list_tools）后终于能调 submit_github_issue，但确认卡片上中文乱码，连续两次提交被用户取消。
3. 最后是用户自己「拍脑门」想起来：去 Cindy 插件列表里手动启用 GitHub 插件，才真正弹出可用的确认卡片，第三次提交成功（纯文本模型下对话历史含图片导致请求被拒，会话卡死在报错界面 #1870）。

整条链路全靠用户灵光一现，普通用户走到这一步大概率直接放弃。默认未安装的插件 + 无指向性的错误信息 + 文档缺失，让官方 /issue 反馈入口形同虚设。

版本区域: CN
OS: win32 x64 (10.0.26100)
界面语言: zh-CN

[dash-s-cindy]

判断：值得处理，但该 Issue 的结论是部分准确。当前实现并非要求 Cindy GitHub 插件必须启用后才能使用 /issue：未启用、未绑定或当前项目停用插件时，系统会回退到 Cindy 平台代提交；启用并绑定有效账号时，才使用用户本人 GitHub 身份。因此，“缺少 GitHub 插件会导致官方反馈入口完全不可用”目前不能由源码确认。可以确认的是，首次使用时缺少对两种提交身份和配置入口的说明；另外，Codex MCP 策略层对会话上下文无法验证时返回的是泛化错误，没有指出具体插件或恢复步骤。作者报告的中文乱码也需要单独复现，当前源码不足以证明它已修复或仍然存在。

行动：建议先按“可发现性和错误引导”推进，不把 GitHub 插件设为 /issue 的硬性前置条件：

1. 在 /issue 能力说明和相关帮助文案中明确：反馈可以由 Cindy 平台代提交；如果希望以本人 GitHub 身份提交，则需在“插件 → Cindy GitHub”启用插件并绑定账号。
2. 复现插件未安装、未启用、未绑定、凭证失效，以及启用插件后继续使用旧会话和新会话的行为。确认平台代提交路径是否始终可用；若确实被策略层阻断，则修复为具体、可操作的插件状态提示，而不是统一返回 could not verify this session's tool policy。
3. 在 Windows zh-CN 实机验证确认卡的标题、正文、身份说明、环境信息和按钮文案，单独跟踪作者报告的乱码问题。
4. 保留当前身份一致性约束：确认卡显示的身份必须与实际提交身份一致，用户身份提交失败时不得静默切换为平台身份。

技术依据：

• packages/lizi-mcps/src/xdt-helper/submit_github_issue.ts 的工具说明已经规定：启用并绑定有效的 Cindy GitHub 时使用 GitHub 用户身份；未绑定或插件不可用时使用 Cindy 平台身份；确认卡片是提交前的必经路径。
• apps/desktop/src/main/github-issue/githubUserIssueSubmitter.ts 中，isCindyGithubGhostUsable() 同时检查插件启用状态、凭证是否保存以及当前工作目录是否停用插件。不满足条件时返回平台身份；已绑定但凭证失效时返回 AUTH_NOT_READY，不会伪装成未绑定状态。
• apps/desktop/src/main/github-issue/githubIssueSubmitService.ts 会在确认前解析并展示提交身份，确认后不会静默切换身份。
• apps/desktop/src/renderer/features/cc-agent/IssueConfirmCard.tsx 已支持标题/正文编辑、反馈类型切换、提交身份展示、环境信息展示以及 i18n 文案。
• apps/desktop/help-knowledge/connections.md 和生成的帮助内容已经把 GitHub 配置入口指向“插件 → Cindy GitHub”，但 packages/lizi-mcps/src/xdt-helper/capabilities.ts 的“官方反馈提交”说明尚未明确区分平台代提交与用户 GitHub 身份提交。
• apps/desktop/src/main/mcp-integrations/codexHttpBridge.ts 对缺失或无法验证会话策略的情况统一返回泛化错误文本，当前未看到面向用户的具体插件引导。
• PR #668 当前未合并（closed，merged: false），不能作为本快照已经修复本问题的依据；该 PR 讨论的是通用插件 readiness，也没有覆盖 /issue 的提交身份提示或确认卡链路。

建议验收矩阵：

状态	预期行为
未安装 Cindy GitHub	/issue 可走平台代提交，并明确显示平台身份
已安装但未启用	同上，并提示启用插件可改用本人 GitHub 身份
已启用但未绑定	同上，并提供“插件 → Cindy GitHub”入口提示
已绑定有效账号	确认卡显示 GitHub 用户名，按该身份提交
已绑定账号凭证失效	返回重新配置/测试连接提示，不降级为平台身份
插件启用后复用旧会话	行为符合会话策略生效规则；若需新会话，应明确提示
Windows zh-CN	确认卡及最终 Issue 正文无乱码，环境信息与界面语言一致

[dash-s-cindy]

Cindy 你来检查优化一下，照理我们应该不依赖用户的任何Github状态，直接通过官方bot就能提交issue。使用用户自己账号只是一个额外的选项，只在用户当前已配置github账号的情况下出现。

来自 Slack #cindy-issue · @dashhuang

[dash-s-cindy]

⚙️ 工作中 · 323 项 · 86m
> ✓ 查看代码变更
> ✓ 运行测试
> ✓ 类型检查
> ✓ ✦ Planning typecheck polling
> ▸ 运行命令

最终门禁遇到一个与本次改动无关的 Mobile 启动画面测试 5 秒超时；其余 3224/3225 项通过。此前两次全量门禁都通过。我会先单独复跑这条测试确认是否是偶发超时，再完整重跑门禁；在门禁重新全绿前不会提交。

来自 Slack #cindy-issue

[dash-s-cindy]

https://github.com/makecindy/cindy-official-plugins/pull/73|github.com/makecindy/cindy-official-plugins/pull/73
插件我已经昨天修了，核心是插件不支持GH命令。但用户又开了，理论上会跳出要填token的对话框的。以后升级插件后就不会弹了，ai会引导使用本地gh或者帮配置gh的。

来自 Slack #cindy-issue · @zqchris

[dash-s-cindy]

Task failed: Task timed out: Desktop stayed offline; task recovery expired while waiting

来自 Slack #cindy-issue