[codex] add Wework local model settings

docs/en/developer-guide/wework-cloud-connection.md

@@ -4,7 +4,7 @@ sidebar_position: 32
 
 # Local-First Cloud Connection
 
-Wework remains a complete local app by default. Local Codex, the local executor, local workspaces, and local conversations do not require Backend login or cloud devices. Cloud connection is an optional capability layer: after the user enters a Backend URL from the sidebar and signs in with the WeWork login flow, server models, cloud devices, and cloud Codex auth sync join the same workbench.
+Wework remains a complete local app by default. Local Codex, local model configs, the local executor, local workspaces, and local conversations do not require Backend login or cloud devices. Cloud connection is an optional capability layer: after the user enters a Backend URL from the sidebar and signs in with the WeWork login flow, server models, cloud devices, and cloud Codex auth sync join the same workbench.
 
 ## State Ownership
 
@@ -27,31 +27,46 @@ The desktop sidebar shows the cloud entry near the bottom:
 
 Settings are grouped by capability:
 
-- Default features: local Codex, local executor, local workspaces, and local conversations.
+- Default features: local Codex, local model configs, local executor, local workspaces, and local conversations.
 - After connecting cloud: server models, cloud devices, cloud Codex `auth.json` sync, proxy, and remote device management.
 
-Cloud devices, proxy configuration, and cloud Codex auth sync must use the cloud connection. When disconnected, pages show a connection entry or disabled state and do not write local state to the server.
+"Model Settings" is the shared entry for local models and Codex `auth.json`. Local model configs are always available; cloud Codex auth sync, upload, import, and proxy switches must use the cloud connection. When disconnected, the page only shows local auth status and cloud feature guidance and does not write local state to the server.
 
 ## Service Merge
 
 Workbench services have three layers:
 
-1. `createLocalAppServices()` provides local IPC, the local device, local runtime work, and local Codex models.
+1. `createLocalAppServices()` provides local IPC, the local device, local runtime work, local Codex models, and user-configured local models.
 2. `createBackendWorkbenchServices()` wraps Backend HTTP, Socket.IO, models, devices, and runtime work APIs.
 3. `createHybridWorkbenchServices()` merges local and cloud services when cloud is connected.
 
 When disconnected, Wework continues to use local services only. When connected, models, devices, and runtime work lists are merged; execution and stream subscriptions route to local IPC or Backend relay by device or source.
 
 ## Model Naming
 
-The frontend merge layer must avoid name collisions between local Codex and cloud-synced Codex models. The UI uses unique names:
+The frontend merge layer must avoid name collisions between local Codex, user-configured local models, and cloud-synced Codex models. The UI uses unique names:
 
 ```text
 local:runtime:codex-gpt-5.5
+local:runtime:local-model:<config-id>
 cloud:runtime:codex-gpt-5.5
 ```
 
-Before execution, `weworkExecution` metadata on the selected model maps the UI name back to the original `modelName` and `modelType`. The local IPC execution boundary then normalizes local Codex UI model names to the real model id accepted by Codex app-server; for example, `codex-gpt-5.5` is converted to `gpt-5.5` before sending. Cloud relay paths continue to pass the original execution model name for their source.
+Before execution, `weworkExecution` metadata on the selected model maps the UI name back to the original `modelName` and `modelType`. The local IPC execution boundary then normalizes local Codex UI model names to the real model id accepted by Codex app-server; for example, `codex-gpt-5.5` is converted to `gpt-5.5` before sending. User-configured local models use `local-model:<config-id>` and can only be sent to a local device; if the target is a cloud task, the frontend blocks sending and asks the user to switch device or model. Cloud relay paths continue to pass the original execution model name for their source.
+
+The local Codex model catalog follows only the active provider in the current Codex configuration. executor reads `config/read` once through Codex app-server to get the active `model_provider` and display name, then calls `model/list` once for that provider's catalog. Even when `config.toml` contains multiple `[model_providers.*]` entries, Wework does not enumerate them as parallel model groups because Codex `model/list` does not expose a stable provider-scoped query protocol. Use the local model config flow below when Wework needs to show multiple model interfaces.
+
+## Local Model Configs
+
+Local model configs are stored in local browser storage. They are not written to Backend and are not cloud-synced. Each config includes:
+
+- Display name.
+- Model ID.
+- OpenAI Responses-compatible model URL.
+- Optional API Key.
+- Enabled state and update time.
+
+When API Key is blank, local runtime sends a `dummy` bearer token to the Codex provider config so no-auth local OpenAI-compatible services can run. Local model configs and the built-in local Codex model enter the existing model selector as `UnifiedModel(type: "runtime")`.
 
 ## Local Auth Status
 
@@ -63,7 +78,7 @@ Local Codex `auth.json` status is read through the executor's read-only `runtime
 - File size.
 - SHA-256 digest.
 
-It never returns plaintext contents. Wework also does not upload the local auth file by default. Auth contents enter encrypted server storage and device sync only after the user explicitly uploads the file or imports it from an online device on the cloud Codex auth page.
+It never returns plaintext contents. Wework also does not upload the local auth file by default. Auth contents enter encrypted server storage and device sync only after the user explicitly uploads the file or imports it from an online device on the cloud-connected "Model Settings" page.
 
 ## Disconnect
 
@@ -72,6 +87,7 @@ Disconnecting cloud only clears cloud connection storage. It does not affect:
 - Local conversations.
 - Open local workspaces.
 - Local Codex models.
+- Local model configs.
 - The local executor.
 
 After disconnecting, cloud devices, server models, proxy, and cloud auth sync return to unavailable or connect-entry states.

docs/zh/developer-guide/wework-cloud-connection.md

@@ -4,7 +4,7 @@ sidebar_position: 32
 
 # 本地优先云端连接
 
-Wework 默认是完整本地应用。本机 Codex、本地 executor、本地工作区和本地会话不依赖 Backend 登录或云端设备。云端连接是一个可选能力层：用户在侧栏输入 Backend 地址并完成 WeWork 登录后，服务端模型、云设备和云端 Codex 认证同步会加入同一个工作台。
+Wework 默认就是一个完整的本地应用。本机 Codex、本地模型配置、本地 executor、本地工作区和本地会话不依赖 Backend 登录或云端设备。云端连接是一个可选能力层：用户在侧栏输入 Backend 地址并完成 WeWork 登录后，服务端模型、云设备和云端 Codex 认证同步会加入同一个工作台。
 
 ## 状态归属
 
@@ -27,31 +27,46 @@ Wework 默认是完整本地应用。本机 Codex、本地 executor、本地工
 
 设置页按能力分组：
 
-- 默认功能：本机 Codex、本地 executor、本地工作区和本地会话。
+- 默认功能：本机 Codex、本地模型配置、本地 executor、本地工作区和本地会话。
 - 连接云端后：服务端模型、云设备、云端 Codex `auth.json` 同步、代理和远程设备管理。
 
-云设备、代理配置和云端 Codex 认证同步都必须通过云端连接访问。未连接时页面展示连接入口或禁用态，不会把本机状态误写入服务端。
+“模型设置”是本地模型和 Codex `auth.json` 的统一入口。本地模型配置始终可用；云端 Codex 认证同步、上传、导入和代理开关都必须通过云端连接访问。未连接时页面只展示本机 auth 状态和云端能力说明，不会把本机状态误写入服务端。
 
 ## 服务合并
 
 工作台服务由三层组成：
 
-1. `createLocalAppServices()` 提供本地 IPC、本机设备、本地运行时任务和本机 Codex 模型。
+1. `createLocalAppServices()` 提供本地 IPC、本机设备、本地运行时任务、本机 Codex 模型和用户配置的本地模型。
 2. `createBackendWorkbenchServices()` 封装 Backend HTTP、Socket.IO、模型、设备和运行时任务 API。
 3. `createHybridWorkbenchServices()` 在云端已连接时合并本地和云端服务。
 
 未连接时，Wework 继续只使用本地服务。已连接时，模型、设备和 runtime work 列表合并展示；执行和流式订阅按设备或来源路由到本地 IPC 或 Backend relay。
 
 ## 模型命名
 
-前端合并层必须避免本机 Codex 和云端同步 Codex 的模型名冲突。UI 使用唯一名称：
+前端合并层必须避免本机 Codex、用户配置本地模型和云端同步 Codex 的模型名冲突。UI 使用唯一名称：
 
 ```text
 local:runtime:codex-gpt-5.5
+local:runtime:local-model:<config-id>
 cloud:runtime:codex-gpt-5.5
 ```
 
-执行前通过模型上的 `weworkExecution` 元数据映射回原始 `modelName` 和 `modelType`。本地 IPC 执行边界再把本机 Codex UI 模型名规范化为 Codex app-server 接受的真实模型 id，例如 `codex-gpt-5.5` 会在发送前转换为 `gpt-5.5`。云端 relay 仍按模型来源传递原始执行模型名。
+执行前通过模型上的 `weworkExecution` 元数据映射回原始 `modelName` 和 `modelType`。本地 IPC 执行边界再把本机 Codex UI 模型名规范化为 Codex app-server 接受的真实模型 id，例如 `codex-gpt-5.5` 会在发送前转换为 `gpt-5.5`。用户配置的本地模型使用 `local-model:<config-id>`，只允许投递到本机 device；如果目标是云端任务，前端会阻止发送并提示用户切换设备或模型。云端 relay 仍按模型来源传递原始执行模型名。
+
+本机 Codex 模型目录只跟随当前 Codex 配置中的 active provider。executor 通过 Codex app-server 读取一次 `config/read` 获取当前 `model_provider` 和展示名，再调用一次 `model/list` 获取该 provider 对应的模型列表。即使 `config.toml` 中配置了多个 `[model_providers.*]`，Wework 也不把它们枚举成多个并列模型组，因为 Codex 的 `model/list` 不提供按 provider 查询的稳定协议。需要在 Wework 中展示多个模型接口时，应使用下方的本地模型配置。
+
+## 本地模型配置
+
+本地模型配置存储在浏览器本机存储中，不写 Backend，也不参与云端同步。配置字段包括：
+
+- 显示名。
+- 模型 ID。
+- OpenAI Responses 兼容模型 URL。
+- 可选 API Key。
+- 启用状态和更新时间。
+
+API Key 留空时，本地 runtime 会向 Codex provider 配置传入 `dummy` bearer token，用于支持无鉴权的本地 OpenAI-compatible 服务。本地模型配置和内置本机 Codex 模型都会以 `UnifiedModel(type: "runtime")` 进入现有模型选择器。
 
 ## 本机认证状态
 
@@ -63,7 +78,7 @@ cloud:runtime:codex-gpt-5.5
 - 文件大小。
 - SHA-256 摘要。
 
-它不会返回明文内容。Wework 也不会默认上传本机认证文件。只有用户在云端 Codex 认证页面显式上传或从在线设备导入后，认证内容才进入服务端加密存储和设备同步流程。
+它不会返回明文内容。Wework 也不会默认上传本机认证文件。只有用户在已连接云端的“模型设置”页面显式上传或从在线设备导入后，认证内容才进入服务端加密存储和设备同步流程。
 
 ## 断开连接
 
@@ -72,6 +87,7 @@ cloud:runtime:codex-gpt-5.5
 - 本地会话。
 - 已打开的本地工作区。
 - 本机 Codex 模型。
+- 本地模型配置。
 - 本机 executor。
 
 断开后，云设备、服务端模型、代理和云端认证同步回到不可用或连接入口状态。

executor/src/agents/codex.rs

@@ -203,7 +203,10 @@ impl CodexAppServerClient {
 }
 
 fn codex_app_server_request_is_retryable(method: &str) -> bool {
-    matches!(method, "thread/list" | "thread/read")
+    matches!(
+        method,
+        "thread/list" | "thread/read" | "config/read" | "model/list"
+    )
 }
 
 struct CodexAppServerProcess {