Tabbit 已经更新了多个版本，欢迎各位大佬踊跃PR进行适配！

[hwttop5]

如题

[hechushitaoyuan]

好的，给你整理了一份约 300 字的详细版，直接复制粘贴即可：

---

感谢作者的项目，Windows 下部署整体很顺畅，但在网关就绪这一步卡了挺久，特来反馈一个文档缺漏，希望能帮到后续用户。

环境： Windows 11、Node v24.12.0、Tabbit 已安装并完成登录（profile 已生成）。

现象： 执行 tabbit2api start 后控制台只输出一行 gateway listening on http://127.0.0.1:50124，之后再无任何日志。反复 tabbit2api doctor 一直显示 /health: ok (200, runtimeInitialized=false)，调用 /v1/models 返回 {"error":{"Missing or invalid API key"}}。由于日志几乎为空，新人无从判断是登录失败、桥接失败还是端口占用，排查成本很高。

根因： 网关需要环境变量 TABBIT_API_KEY 做鉴权，未设置时所有请求一律被拒；而 runtime 恰恰需要一次「带合法 key 的成功请求」才会触发初始化——于是陷入「未初始化」与「鉴权失败」相互遮掩的死锁表象。

修复： 先 set TABBIT_API_KEY=任意字符串，再 start，请求时带上 Authorization: Bearer <该 key>，runtime 立即转为 true，模型列表正常返回。

建议： 能否在仓库里补一节说明，明确「首次启动前需先配置 TABBIT_API_KEY 环境变量」，并给出最小示例（key 可任意填）。若能像 executable / user data 那样，在 doctor 里增加 api key : not set ⚠️ 一项，或 start 时自动生成并打印，体验会好很多。把这一步写进 README，既能避免真人用户踩坑，也能让阅读仓库的 AI 编程助手快速理解部署流程、给出正确指引。

——来自 ZCode 的反馈

[hwttop5]

感谢反馈，这里确实容易让首次使用者误判，我会把 README / doctor 的提示再写清楚一些。

补充澄清一下：当前版本并不是必须设置 TABBIT_API_KEY 才能用。默认本地占位 key 是 sk-tabbit-local，所以最小验证命令应该是：

curl.exe -H "Authorization: Bearer sk-tabbit-local" http://127.0.0.1:50124/v1/models

/health 的 runtimeInitialized=false 本身不是错误，因为健康检查不会主动启动 Tabbit runtime；真正触发初始化的是带合法 key 的 /v1/models、/v1/responses、/v1/chat/completions 等兼容接口请求。

你看到的 Missing or invalid API key 更像是请求兼容接口时没有带 Authorization，或者启动时配置了自定义 TABBIT_API_KEY / --api-key，但调用时仍用了另一个 key。

这个反馈有价值：我后续会补一段“首次启动后的最小验证流程”，并考虑让 doctor 对默认 key、自定义 key，以及 runtimeInitialized=false 的含义给出更明确的下一步提示。

[hechushitaoyuan]

好的，只写问题二，约 500 字，精准详细，可直接复制。下面的诊断日志、根因、建议都写进去了：

---

感谢作者的项目！我用 tabbit2api（v0.1.3，Windows 11，Node v24.12.0）把本地网关接给 Codex 桌面端（wire_api="responses"，走 /v1/responses）使用，主对话请求 100% 失败，特来详细反馈，附排查证据。

现象：Codex 发任何消息都返回 503 Service Unavailable: [492] 欢迎使用 Tabbit 浏览器（https://www.tabbitbrowser.com/），可免费使用最全最先进的模型，url 指向 http://127.0.0.1:50124/v1/responses。但同一网关、同一模型 tabbit/Default，用 curl 发 chat/responses 请求都稳定成功。

排查过程：我在 tabbit-web-bridge.js 的 sendUsingPageModule 调用前后加了诊断日志，记录每次发送给 Tabbit 的 prompt 长度和原始返回。发现了两个层面的问题：

其一，Codex 会请求它本地缓存里 OpenAI 原生的模型名（如 gpt-5.4-mini、codex-auto-review），这些不在 Tabbit 目录中，网关返回 400「Unknown model」，触发 Codex 重试风暴。我在 tabbit-bridge-core.js 的 normalizeRequestedModelId 加了别名表把它们重定向到 tabbit/Default，已验证可正常返回——但只是绕过，不是根因。

其二（真正的根因），诊断日志清楚显示：一条 1233 字符的请求 ok=true text="pong"；而所有失败请求的 prompt 长度都在 30705～47555 字符，全部 detail=[492]。即 Tabbit 网页聊天框对单条输入有长度上限，Codex 这种 agent 客户端的 system instructions + 工具定义 + 对话历史动辄数万字，直接超限，网页端返回 [492] 欢迎使用 Tabbit 浏览器 推广页。证据：promptLen=1233→ok=true，promptLen=47555→detail=[492]，阈值非常明显。

这是网页桥接方案的结构性短板：把超长 prompt 喂进前端聊天框，必然撞上前端输入限制。

建议（根治方向）：希望作者评估能否在桥接层绕过网页聊天框，改走 Tabbit 内部 API（webpack 注入已能拿到内部 require，似乎有机会直接调用内部 chat 接口而非模拟前端输入），从而原生支持长上下文；或在桥接层做 prompt 分块/智能截断（保留 system 指令核心与工具定义）作为过渡方案。

——来自 ZCode 的反馈

---

这一份聚焦问题二，证据齐全、因果链清晰。提完 issue 你就可以睡了，晚安！明天想继续弄（比如我帮你用二分法测出 Tabbit 的精确长度阈值，或评估 ken861222 那个 CDP 内部 API 版能不能绕过这个限制）随时找我。

[hwttop5]

@luluxiaoyu 你想走 Tabbit 内部 API估计够呛，你可以让AI去实践一下试试，期待你的PR

[luluxiaoyu]

@luluxiaoyu 你想走 Tabbit 内部 API估计够呛，你可以让AI去实践一下试试，期待你的PR

前端确实是限制了20000字符输入好像是

[hwttop5]

本轮当前 Tabbit 适配已经完成，并随 v0.1.8 发布。

本次包含：

• 当前 Tabbit 登录状态结构和 /login 页面识别；
• 新会话导航上下文销毁重试；
• 旧 sendMessage 模块移除后的 UI 发送 fallback；
• [492] 登录、输入超限和模型不可用分类；
• tabbit/priority 动态免费模型及 tabbit/Default 最终兜底；
• Windows 自定义安装路径、App Paths 和 doctor 诊断改进。

验证包括 97 项自动测试、OpenAI / Anthropic / SSE 真实请求、Codex CLI、Claude Code、第三方 OpenCode 客户端，以及 npm 已发布包真实调用。

Release： https://github.com/hwttop5/tabbit2api/releases/tag/v0.1.8