正常对话时报 403 错误：Error invoking remote method 'codesign:v1:generate'

[Sun-sunshine06]

问题描述

测试连接时正常，但进行正常对话时弹出错误：

Error invoking remote method 'codesign:v1:generate': CodesignError: 403 Your request was blocked.

复现步骤

1. 在设置中测试 API 连接 → 正常通过
2. 在对话界面发送消息 → 报 403 错误

[Sun-sunshine06]

正在修复此问题。测试连接和实际调用的请求方式可能存在差异（如 model 参数、请求头、endpoint 不同），导致 403 策略拦截。

[github-actions]

感谢反馈，复现描述很清楚。

从当前代码看，这个现象是可能出现的：“测试连接”与“正常对话生成”走的是不同请求路径。

• 设置页“测试连接”只探测 provider 的 /models 可达性与鉴权。
• 聊天对话会走 codesign:v1:generate，再进入真实的生成请求（模型推理调用）。

所以会出现“测试连接通过，但生成时报 403（Your request was blocked）”的情况：/models 可用不代表生成端点一定放行。

另外，当前诊断里会把 403 和 401 归到同一类（密钥/权限问题），因此提示可能偏泛化。

Relevant code:

• apps/desktop/src/renderer/src/components/Settings.tsx:286 — 设置页“测试连接”调用 connection.testProvider(...)
• apps/desktop/src/main/connection-ipc.ts:410 — runProviderTest 仅对 /models 做 GET 探测
• apps/desktop/src/main/connection-ipc.ts:426 — 非 2xx 时按 HTTP 状态返回连接测试错误
• apps/desktop/src/main/index.ts:448 — 对话生成走 codesign:v1:generate
• apps/desktop/src/main/index.ts:581 — 生成调用 runGenerate(...)（真实模型请求）
• apps/desktop/src/main/connection-ipc.ts:205 — 403 被归类为 401 类别
• packages/shared/src/diagnostics.ts:61 — 诊断里 401/403 同归 keyInvalid
• README.md:119 — 当前发布仍是 v0.1.x 早期阶段

Need more info:

• 你当前“激活中的 provider / model / baseUrl”分别是什么？
• 是否使用了中转网关或自定义 baseUrl（以及是否配置了额外请求头）？
• 请在 Settings → Storage 导出 diagnostics zip，并附上。
• 请贴一段 main.log 里对应 generate.fail 的日志（包含 provider、modelId、baseUrl、message）。

---

open-codesign Bot

[Sun-sunshine06]

补一条同类现场证据，和本 issue 高度一致：

• 现象：生成阶段报错，弹窗内容为

Error invoking remote method 'codesign:v1:generate': CodesignError: 403 Your request was blocked.

• 用户补充：无论是 codex 还是 claude 都不行，是 cpa 反代的
• 截图显示：UI 仍然只是通用的“生成失败 / 生成过程中出错了”，没有给出更可操作的代理/上游拦截解释

这条证据进一步支持当前判断：

• 测试连接可通过，不代表真实生成请求会通过
• 在反代 / 中转 / 自定义 provider 场景下，生成请求路径更容易被上游策略拦截
• 问题并不局限于单一模型，至少用户反馈里 codex 和 claude 两条链路都可能触发同类 403 blocked

建议把这类 case 一并纳入该问题，而不是按单个模型拆散处理。若后续需要，可再补 diagnostics zip / main.log 佐证。

[Sun-sunshine06]

Another potentially related signal: see #136.

In at least one user screenshot, the top bar shows the active model as opus-4-7, while the currently active provider card in Settings shows claude-3-5-haiku-20241022 and is still marked 当前.

That suggests the UI may be exposing two different model states at once (top-bar active vs provider-card default/resolved state). If true, this could make 403 debugging much harder because the user may think the generate request is using one model while the app internally resolves another.

[hqhq1025]

@Sun-sunshine06 同步一下进度 —— 你 4/22 02:51 提到正在修复，请问目前进度如何？

我这边正在并行做一个更通用的修复 PR（暂编号 #130 范围），把生成失败路径接到现有的 diagnose() hypothesis 系统，覆盖范围包括：

• 404 + custom baseUrl 不含 /v1 → missingV1 hint + auto-fix
• 403 + body 含 Your request was blocked / blocked / Cloudflare ray id → 新增 gatewayWafBlocked hint（专门给本 issue 这种 WAF 拦截场景，避免被误归到 keyInvalid 让用户白查 API key）
• 401/403 不含 WAF 文案 → 维持 keyInvalid
• 500 + not implemented → 网关不支持 Messages API hint（与 bug: 第三方中转服务测试连接通过但生成返回 500 not implemented #158 联动）
• 400 + instructions are required → 提示切换 wire 到 openai-chat（与 bug(desktop): macOS generation fails with Instructions are required and no visible output #134 联动）

如果你那边的修复方向不同/已经动手，麻烦贴一下 PR 链接或当前思路，避免重复工作。如果还没起手，我这个 PR 落地后会顺带 close 本 issue，你来 review 即可。

cc @hqhq1025

[Sun-sunshine06]

明白了！我这边只是做了问题整理和分析，还没有实际动手改代码。这个问题你已经分析得很清楚了，尽管放开手去改，我来帮你 review 合并 👍