在 Codex（ChatGPT 桌面版）的插件页安装或连接插件，浏览器里授权已经通过，回到应用却弹出 OAuth state not found，这不是你的账号、浏览器或第三方服务出了问题。失败点在 OpenAI 自己的回调接口：它找不到应用刚刚发起的那次授权记录，直接返回 404。截至 2026 年 10 月 22 日，这个 bug 在 GitHub 上仍未关闭，OpenAI 没有回复，也没有发布修复。
能做的是绕开桌面版发起的这条授权链路。目前有效反馈最多的办法是改在 chatgpt.com 网页端发起同一个连接，连好后桌面版会同步过来；但并非人人有效，下面每条路线都标了依据强弱。重新登录、重建连接、更新应用这几招已经有人试过，都没解决。
按你要连的插件选绕法：四条路线和各自的依据
先看你要连的是什么，直接跳到对应一节：
| 你要连的 | 先试什么 | 依据强弱 |
|---|---|---|
| GitHub、Slack、Figma、Webflow、Firecrawl 等托管插件 | 在 chatgpt.com/plugins 网页端发起连接，再回桌面版 | 多位用户反馈有效，也有两位反馈无效 |
| OpenAI Developers 插件（想让 Codex 帮你建 API key） | 在网页端插件页的 Apps 区块连接 OpenAI Platform，不行再用手机版 | 单个用户的详细报告；手机版路径也是单个用户 |
| 你自己的 MCP 服务器（自定义地址，带 OAuth） | 用 codex mcp login 在本机完成授权 | 命令出自官方文档；能绕过此 bug 只有单个用户反馈 |
| 其实只想要一个 OpenAI API key | 在 platform.openai.com 手动创建 | 官方文档 |
另有一种情况长得像，但不是同一个故障：Windows 上点 Install plugin 后直接报 Failed to install plugin，日志里有 os error 32。那是还没走到授权就失败了，处理方法见安装时报 os error 32。
OAuth state not found 出在哪一步：OpenAI 托管回调返回 404
OAuth 里的 state 是一张"对号牌"：应用发起授权时在 OpenAI 服务器上登记一条待完成的记录，浏览器授权完跳回来时带上它，服务器据此确认"这次回跳属于刚才那次发起"。OAuth state not found 的意思是服务器那边查不到这条记录。
几位用户在 GitHub 上贴出的桌面版诊断日志（已去掉敏感值）把失败点定位得很清楚（见 #54924、#54626、#55314）：
- 桌面版登记了一次待完成的 OAuth 授权；
- 浏览器里的授权正常完成，第三方页面没有报错；
- 桌面版收到了回跳，并确认这次回跳是自己发起的（日志里
callbackOwned=true）； - 桌面版调用 OpenAI 的
POST /aip/connectors/links/oauth/callback，在发起后约 3 到 9 秒返回 HTTP 404：{"detail":"OAuth state not found"}。
有一位自建 MCP 服务器的用户对比了四次完整的授权往返，服务器每次都把收到的 state 原样送回了指定的回调地址；另一位用户删掉连接器重新注册，同样失败。所以问题不在第三方服务，也不在你的浏览器。从发起到报错只隔几秒，用"浏览器标签页放久了、state 过期"来解释也说不通——这一点是根据时间推断的，OpenAI 没有公布根因。
下面这些做法已经有人试过，都没有解决（每条只有一两位用户，结果可能因账号而异）：
- 桌面版重启、退出登录再登录（#54924 原帖，以及一位用户的完整重登）；
- 在网页端退出再登录 ChatGPT，然后回桌面版重试；
- 删掉连接器重新创建；
- 更新桌面版后重试（#55955）；
- 先在网页端连好 Slack，再回桌面版重新连一次。
最后一条值得注意：网页端连好之后，回桌面版先直接用，不要再从桌面版点连接。重新发起会再走一遍出错的链路，那位 Slack 用户就是这样又看到了报错。
受影响的范围：这一波报告从 2026 年 10 月 16 日开始，几乎都是 Windows 上的桌面版，报告里出现过的版本有 26.1013.40934（Windows 安装包 26.1013.4894.0）和 26.1016.51333。涉及的插件包括 OpenAI Developers、GitHub、Slack、Webflow、Meta、Figma、Firecrawl，以及自建的 OAuth MCP 服务器。不过它不能算 Windows 独有：有一位用户在 Windows 的网页端也遇到了；2026 年 4 月，OpenAI 社区论坛上还有开发者在 macOS 的 Chrome 网页端配置自建 MCP 连接器时遇到过同样的 404（论坛帖）。
托管插件：改在 chatgpt.com/plugins 网页端发起连接
适用于 GitHub、Slack、Figma、Webflow、Firecrawl 这类在插件目录里直接安装的插件。ChatGPT 和 Codex 共用同一个插件目录（OpenAI 官方说明），所以在网页端连好的插件，桌面版也能用。
- 用浏览器打开 chatgpt.com/plugins，登录的账号必须和桌面版是同一个。要找某个插件可以直接带搜索参数，例如
https://chatgpt.com/plugins/?search=github。 - 在网页端点 Install 或 Connect，完成第三方的授权页面。
- 回到桌面版，不要再点一次连接。如果插件状态没更新，彻底退出桌面版再打开。
- 按下文确认插件真的连上了做一次只读验证。
这一招的反馈：
- 有效：Firecrawl 在网页端连好后，桌面版无需再次授权就能用（#54626）；自建 MCP 在网页端安装后，Codex 里可以调用它的工具（同一帖）；给已装好的 GitHub 插件再加一个 GitHub 账号，改在浏览器里新发起一次流程就成功了（#55314）；GitHub 插件通过网页端链接安装成功（#55656）。
- 无效：一位用户的 Slack 在网页端能连能用，桌面版依然报错；另一位用户用 Sites 托管的自建 MCP，在 Windows 网页端也看到了同样的报错（均见 #54924）。
如果网页端也报 OAuth state not found，就不用在这条路线上反复试了，直接看文末什么时候停止重试。
OpenAI Developers 插件安装失败：在网页端 Apps 区块连接 OpenAI Platform
OpenAI Developers 插件的主要用途是把 ChatGPT 或 Codex 连到 OpenAI API Platform，让 Codex 能直接创建、保存项目的 API key。按官方安装步骤，装插件时如果提示连接内置的 OpenAI Platform 应用，就要完成这一步，插件才能建 key。报错多半就出在这次连接上（#54924、#55955）。
一位 Windows 11 用户（OpenAI Developers 1.3.6，ChatGPT Plus）在 2026 年 10 月 21 日报告了下面这条成功路径（原帖评论）。它和"在网页端登录一下再回桌面版重试"不同，关键在于授权本身由网页端发起：
- 在 ChatGPT 网页端打开 Plugins，进入 OpenAI Developers 插件页；
- 在插件页里找到 Apps 区块；
- 找到 OpenAI Platform 这一行；
- 点这一行最右侧的 Connect；
- 在浏览器里完成授权；
- 彻底退出 ChatGPT/Codex 桌面版（不只是关掉窗口）；
- 重新打开桌面版。
重启后 OpenAI Platform 显示已连接的账号，OpenAI Developers 保持已安装、已启用。
网页端找不到 Connect 按钮：用手机版 ChatGPT 连接
另一位用户在网页端的 OpenAI Platform 下面看不到 Connect 按钮。他改用手机版 ChatGPT 安装并连接 OpenAI Developers，成功后桌面版自动同步，可以正常使用（#54924，单个用户反馈）。
两条路径都只有一位用户验证过，不保证对你有效。都不行的话，如果你的目标只是拿到 API key，可以直接手动创建。
自建 MCP 服务器：用 codex mcp login 在本机完成授权
如果你连的是自己的 MCP 服务器（一个带 OAuth 的 HTTP 地址），除了网页端，还有一条不经过插件页的路：把服务器直接写进 Codex 的 MCP 配置，再用命令行登录。按 Codex MCP 官方文档，桌面版、Codex CLI 和 IDE 扩展共用同一份 ~/.codex/config.toml 里的 MCP 配置。
# 把服务器加入 Codex 配置（名称自取，地址换成你的 MCP 端点）
codex mcp add my-server --url https://mcp.example.com/mcp
# 发起 OAuth 登录
codex mcp login my-server
# 授权服务器只支持某一种客户端注册方式时，可以指定 cimd 或 dcr
codex mcp login my-server --oauth-client-registration cimd
# 查看已配置的服务器
codex mcp listcodex mcp login 的授权会回跳到本机的回环地址（形如 http://127.0.0.1:<端口>/callback/...），需要固定端口时可以设置 mcp_oauth_callback_port。一位用户的自建服务器在桌面版插件页连接失败，同一个服务器用 codex mcp login ... --oauth-client-registration cimd 登录成功，之后的读取也正常（#54924）。不过他也说明，之后那次读取可能用的是早先缓存的凭据。
它为什么能绕开这个 bug：命令行登录在本机回环地址上完成回调，不经过返回 404 的那个托管接口。这是根据两边的回调方式推断的，只有一例实际成功。
两个限制：这条路只适用于你自己有地址的 MCP 服务器，GitHub、Slack 这类托管插件不能这样接；另外官方文档也提醒，直接配置的 MCP 服务器和托管插件提供的工具能力可能不同。
只想要 API key：在 platform.openai.com 手动创建
很多人装 OpenAI Developers 插件，只是想让 Codex 帮当前项目配好 API key。这一步可以按 OpenAI 官方快速入门手动完成：
- 打开 platform.openai.com/api-keys，为你的项目创建一个 key；
- 把它设为环境变量
OPENAI_API_KEY。
# macOS / Linux
export OPENAI_API_KEY="你的 key"# Windows PowerShell
setx OPENAI_API_KEY "你的 key"setx 写入的变量只对之后新打开的终端和程序生效，设置完要重开终端。OpenAI 的各语言 SDK 会自动从环境变量读取这个 key。
这样替代的只是插件"引导建 key"这一步，插件建的本来也是项目 API key；插件里的 Agents SDK 搭建、API 报错排查等技能仍然需要插件本身装好。
安装时报 os error 32：OAuth 之前的另一个故障
这个分支只适用于 Windows，并且同时满足两个条件：/plugins 安装 OpenAI Developers 时报 Failed to install plugin: plugin/install failed，而且日志里出现类似下面的内容：
failed to remove stale remote plugin cache entry
...\openai-developers
file is being used by another process
(os error 32)意思是旧的插件缓存目录被某个进程占着，删不掉，安装在授权之前就失败了。报告这一情况的用户是这样解决的（#54924，单个用户反馈）：
- 打开 Windows 的"资源监视器"，切到 CPU 选项卡，在"关联的句柄"里搜索
openai-developers，找出占用缓存的进程。他遇到的是node.exe ./mcp/server.mjs，父进程是 Codex 桌面版的 app server。 - 只结束这一个确认过的进程，再确认句柄已经消失。
- 把那个旧的
openai-developers缓存目录移到别处（不要直接删除）。 - 重新运行
/plugins安装，这次 1.3.6 版装上了。
不要一次性结束所有 node.exe 或 codex.exe 进程。日志里没有 os error 32，或者被占用的不是 openai-developers 缓存，这一节就与你无关。
装上之后，这位用户从桌面版连接 OpenAI Platform 时照样遇到了 OAuth state not found，最后用的是上文网页端 Apps 区块的路径。Windows 上其他由插件缓存或 app-server 引起的启动类报错，见 Codex app-server 启动失败：按报错原文对症修。
怎么确认插件真的连上了：只读验证，不误建 key
报错消失不等于连上了。有一位 Slack 用户在授权后看到工具返回"Authentication for Slack was requested and accepted. Retry this tool call now."，重试时却是 USER_NOT_LOGGED_IN、"app is not connected"（#54924）。所以要用一次实际调用来确认。
OpenAI Developers 可以这样验证，不会真的创建 key（#54924，单个用户的做法）：
- 在桌面版打开 OpenAI Developers，点 Try in a chat（或 Open plugin）；
- 输入
Create an OpenAI API key to use in this project； - 弹出的 OpenAI Platform 组件如果能加载出你的组织和项目列表，就说明连接正常；
- 不想建 key 的话，到这里就停，不要点确认创建。
其他插件：先新开一个对话（官方安装步骤也要求首次使用前新开对话），让插件做一次只读操作，比如让 GitHub 插件读取某个仓库的信息。能拿到结果才算连上；返回 USER_NOT_LOGGED_IN 或"app is not connected"就是没连上。
还有一个容易误判的信号：插件目录或日志里出现 Cloudflare 的 403 / cloudflare_challenge，不代表授权坏了。上面那位 OpenAI Developers 用户遇到过 app/list 返回 403，但已安装列表里 OpenAI Platform 仍是启用、可调用的状态。
什么时候停止重试，给 OpenAI 报 bug 写哪些信息
出现下面任一情况，就别再在桌面版上反复点连接了：
- 网页端发起的连接也报
OAuth state not found； - 对应路线都试过（托管插件试过网页端，OpenAI Developers 试过网页端 Apps 区块和手机版），仍然不行；
- 连接显示成功，但只读验证一直返回未登录。
截至 2026 年 10 月 22 日，OpenAI 状态页从 10 月 14 日起没有关于插件或连接器授权的事故记录（10 月 20 日那次"部分用户认证错误"只影响伊利诺伊州附近、持续约一小时，已回滚，是另一回事）；Codex 更新日志没有相关修复；六个相关的 GitHub issue 都没有 OpenAI 员工回复。根因、修复时间、是否与账号或工作区设置有关、这一波是否影响 Mac 桌面版，目前都没有公开信息。
这时最有用的是把你的情况补到 OpenAI 那边。找到最接近的 issue：OpenAI Developers 用 #54924，GitHub 插件用 #55314 或 #55656，自建 MCP 用 #54626；情况和已有报告一样就点个赞，有新信息再评论。已有的报告通常写这些：
- 应用版本（桌面版"关于"对话框里的版本号）和 Windows 安装包版本；
- Feedback ID（形如
no-active-thread-...）； - 出错的 UTC 时间；
- 插件或服务名称，以及你试过哪条绕法、结果如何。
不要在任何公开位置贴出 token、OAuth 的 state 或 code 值、完整的回调 URL，也不要贴账号 ID 和原始日志。这些不需要，贴出来反而有泄露风险。
Codex 插件授权失败的相关问题
Mac 版 ChatGPT/Codex 会遇到 OAuth state not found 吗？
可能会。这一波报告几乎都来自 Windows 桌面版，但有一例 Windows 网页端，2026 年 4 月还有一例 macOS 网页端（配置自建 MCP 连接器时）。没有证据说明 Mac 不受影响，遇到了按上面的路线处理即可。
重试时建的自建插件删不掉，报 409 怎么办？
这是另一个 bug。删除时返回 409 "Remove this app from the published plugin before deleting it."，到 2026 年 10 月 20 日已经对部分用户恢复；用 ZIP 上传更新过的插件仍然删不掉，报 "App plugin has a non-generated release."。卸载（uninstall）可以正常进行，只是永久删除不行。目前没有用户侧的解决办法，可以在 #54626 补充你的情况。
插件目录显示 cloudflare_challenge，和这个是同一个问题吗？
不是。Failed to load plugins — cloudflare_challenge 是桌面版内置浏览器加载插件目录失败（#55139），发生在你点连接之前；OAuth state not found 发生在授权完成、回到应用之后。
Codex 登录报 Token exchange failed，也是这个问题吗？
不是。Token exchange failed、浏览器卡在 localhost:1455 这类报错是登录 Codex 本身失败，跟连接插件无关，处理方法见 Codex 报错 Token Exchange Failed：先找失败阶段，再重新登录。
