AI 智能体团队聊天本地化部署时，默认 OAuth 回调与 BYOA 配对配置错位
macOS 开发者按默认配置本地运行 Cumora（人类与 AI 智能体同群的团队聊天）时，GitHub OAuth 登录因回调白名单仍指向 5173 端口而被 400 拒绝，而 Vite 实际跑在 5180；BYOA 配对命令又指向生产环境，导致本地 Codex 无法接入。用户通过改写 allowlist 暂时绕过。
目标用户
在本机运行 AI 智能体与人类协作的团队聊天工具的开发者/自托管用户，重点是使用 Claude Code 或 Codex 作为 BYOA 智能体大脑、并想先本地验证的人。
潜在需求
本地开发/自托管场景需要默认配置与实际运行地址一致：OAuth 回调白名单能匹配 Vite 实际端口，BYOA 配对命令默认指向本地服务，从而在投入密钥或云资源前先跑通人类与智能体协作的完整流程。
发生场景
用户在 macOS 上按 README 执行 npm run dev:all，Web 在 localhost:5180、API 在 localhost:5181 正常启动；配置 GITHUB_CLIENT_ID/SECRET 后点 GitHub Login，请求 /auth/start/github?return=http://localhost:5180/ 被默认 allowlist 拒绝，因为默认只含 localhost:5173；同时生成的 computer pairing 命令目标是生产环境，本地 BYOA 无法配对。
来源证据
用户报告在 macOS 上按默认配置本地运行 Cumora 时，GitHub 登录和 BYOA computer 配对都被默认配置阻断；web/API 能正常启动，问题出在 OAuth 回调校验和配对命令指向。
Local macOS setup issues: OAuth return URL rejected and generated computer pairing command targets production ## Summary While setting up **Cumora locally on macOS**, I encountered two issues that prevented **GitHub login** and **BYOA computer pairing** from working with the default local development setup. The web app and API started successfully with: ```bash npm run dev:all ``` Local environment: * Web: `http://localhost:5180` * API: `http://localhost:5181` * OS: macOS * BYOA engine: Codexhttps://github.com/yetone/cumora/issues/1
为什么值得留意
这是新项目第一批真实用户遇到的 onboarding 阻碍，问题具体、可复现且有明确 workaround，说明自托管 AI 协作工具在“本地优先试用”链路上仍有未处理的配置细节。随着 BYOA（自带模型与密钥）成为隐私敏感团队的常用方式，本地启动体验是否顺畅会直接影响第一批采用者能否完成验证。
已有方案
- 手动把 CUMORA_AUTH_RETURN_ALLOWLIST 改为实际 origin（如 http://localhost:5180/）
- 在 GitHub OAuth App 中配置正确的 callback URL 后再登录
未满足部分
- 默认开发配置的 OAuth 回调白名单端口与 Vite 实际端口不一致，需要用户手工改环境变量
- BYOA computer pairing 自动生成的命令指向生产环境，本地配对默认不可用
可能延伸 · 模型推测
- 启动命令自动探测实际端口并写入 OAuth 回调白名单
- BYOA 配对命令增加 --local 参数，或检测本地开发环境后默认指向本地 API
- 为自托管 onboarding 增加配置自检/健康检查，一次性暴露端口与回调不一致
- 将这类本地部署阻塞清单沉淀到文档，供后续 self-host 用户自查
目前未知
- 该问题是否影响所有本地运行 Cumora 的用户，还是仅发生在 macOS + Codex 组合
- 维护者是否已着手修复，还是仍依赖用户手动配置
继续核实
- 除该 issue 作者外，是否还有更多用户在本地部署时遇到同样的 OAuth 端口或配对命令指向问题？
- 相同问题在 Windows/Linux 或 Claude Code 作为 BYOA 引擎时是否同样出现？
- 维护者是否会通过自动探测端口或 --local 参数修复，而不仅是让用户手写 allowlist？
- 用户是否希望有官方一键本地部署/健康检查来降低自托管门槛？