OpenCoworkAI/open-codesign

@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（与 #158 联动）
- 400 + `instructions are required` → 提示切换 wire 到 openai-chat（与 #134 联动）

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

cc @hqhq1025

Thanks for the clear report — this is a valid UX bug and the mismatch you described is plausible from the current code path.

From the code, the top bar and Settings model selector are driven differently at render time:
- Top bar model text comes from `config.modelPrimary` in store (`ModelSwitcher`) and displays that directly.
- Settings active-card selector also starts from `config.modelPrimary`, but its `` options come from `models.listForProvider(provider)`.

If the active model id is not present in the fetched provider model list, the selector can appear to show a different listed model even though the top bar still shows the active one.

One important note: generation currently snaps to canonical active config in main process, so request routing uses cached active provider/model (not just renderer hint), which reduces runtime drift risk.

**Relevant code:**
- `apps/desktop/src/renderer/src/components/ModelSwitcher.tsx:29` — top bar uses `config.provider`/`config.modelPrima...

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.

Related reports that may share the same root cause or at least the same state-sync confusion:

- #124 正常对话时报 403 错误：Error invoking remote method ''codesign:v1:generate''
- #134 macOS generation fails with Instructions are required and no visible output

Why this may be related:
- users believe they are generating with the top-bar model, but Settings may still show a different provider/model state
- if the actual resolved provider/model differs from what the UI suggests, upstream 403 / validation / aborted failures become much harder to interpret
- even if the root cause is not identical, this mismatch is a strong amplifier for provider-side bug reports because it obscures what request config was truly used

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

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

```text
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 佐证。

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

从当前代码看，这个现象是可能出现的：**“测试连接”与“正常对话生成”走的是不同请求路径**。
- 设置页“测试连接”只探测 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...

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