Currently wanman is a local all-in-one tool, which is great for self-hosted use. But when wanman eventually moves toward a hosted/commercial product, there's one constraint worth designing around early: Claude Code requires credentials that live on the user's machine (~/.claude/.credentials.json), so a hosted server can't run CC on behalf of users. Codex works in that environment because it uses standard HTTP APIs with user-supplied keys.
A pattern worth considering: a local-bridge mode where the agent runtime runs on the user's machine and connects to a remote wanman server via WebSocket. The local bridge holds the credentials and repo access; the server handles orchestration and UI. This is the same model used by zouk, where a local daemon bridges to a cloud-hosted coordination server.
Benefits
- CC credentials stay on the user's machine — no credential sharing with a hosted service
- Users don't need to configure a full runtime environment on any server
- Enables CC support for hosted wanman without compromising security
This doesn't require changes to the current local mode — it's an additive deployment option. Happy to discuss protocol design if this direction is on the roadmap.
目前 wanman 是本地 all-in-one 工具，自托管场景很好用。但如果 wanman 未来走向 hosted/商业版，有一个值得提前考虑的约束：Claude Code 需要用户本地的 credentials（~/.claude/.credentials.json），云端服务器无法代用户运行 CC。Codex 在云端能跑是因为它用标准 HTTP API + 用户自己提供的 key。
一个值得考虑的方案：本地 bridge 模式——agent runtime 跑在用户本地机器上，通过 WebSocket 连接远端 wanman server。本地 bridge 持有 credentials 和 repo 访问权，服务端负责编排和 UI。zouk 用的就是这个模式，本地 daemon 通过 WebSocket bridge 连接云端协作服务。
好处
- CC credentials 留在用户机器上，不需要上传给托管服务
- 用户不需要在服务器上配完整的 runtime 环境
- 让 hosted wanman 支持 CC 成为可能
这不影响现有的本地模式，是一个可选的部署形态。如果这个方向在你们的 roadmap 上，很乐意进一步讨论协议设计。
Currently wanman is a local all-in-one tool, which is great for self-hosted use. But when wanman eventually moves toward a hosted/commercial product, there's one constraint worth designing around early: Claude Code requires credentials that live on the user's machine (
~/.claude/.credentials.json), so a hosted server can't run CC on behalf of users. Codex works in that environment because it uses standard HTTP APIs with user-supplied keys.A pattern worth considering: a local-bridge mode where the agent runtime runs on the user's machine and connects to a remote wanman server via WebSocket. The local bridge holds the credentials and repo access; the server handles orchestration and UI. This is the same model used by zouk, where a local daemon bridges to a cloud-hosted coordination server.
Benefits
This doesn't require changes to the current local mode — it's an additive deployment option. Happy to discuss protocol design if this direction is on the roadmap.
目前 wanman 是本地 all-in-one 工具，自托管场景很好用。但如果 wanman 未来走向 hosted/商业版，有一个值得提前考虑的约束：Claude Code 需要用户本地的 credentials（
~/.claude/.credentials.json），云端服务器无法代用户运行 CC。Codex 在云端能跑是因为它用标准 HTTP API + 用户自己提供的 key。一个值得考虑的方案：本地 bridge 模式——agent runtime 跑在用户本地机器上，通过 WebSocket 连接远端 wanman server。本地 bridge 持有 credentials 和 repo 访问权，服务端负责编排和 UI。zouk 用的就是这个模式，本地 daemon 通过 WebSocket bridge 连接云端协作服务。
好处
这不影响现有的本地模式，是一个可选的部署形态。如果这个方向在你们的 roadmap 上，很乐意进一步讨论协议设计。