2026 年 10 月 16 日，我在 Microsoft Edge 中遇到了一个问题：ChatGPT 扩展已经启用，点击图标也能打开侧栏，但聊天界面始终加载不出来。关闭并重新启动 Edge 后，问题依然存在。
经过排查，直接阻断加载的是页面的 CSPframe-ancestors策略：报错列出的允许名单包含 Chrome 商店版扩展的来源，却没有我安装的 Edge 商店版扩展来源。
解决方法：
在 Edge 中安装了 Chrome 商店版的官方 ChatGPT 扩展，侧栏恢复正常。
详细方法在第五节.
记录时间：2026 年 10 月 16 日。不同时间或版本的表现可能变化，请先核对自己的控制台报错是否一致。
一、问题现象与使用环境
故障出现时，扩展本身没有被禁用，但打开的扩展的侧栏界面不能正常显示。
浏览器生成的灰色阻止页面，带有禁止图标。
本次排查对应的环境如下，版本均为此次故障期间记录的快照：
| 项目 | 版本或信息 |
|---|---|
| 操作系统 | Windows 11 家庭版中文版，26H2，x64 |
| Windows 构建号 | 26300.9457 |
| Microsoft Edge | 155.0.4283.45 |
| 桌面应用安装包 | OpenAI.Codex 26.1013.3656.0 |
| ChatGPT 扩展版本 | 1.26.1006.11559 |
| 扩展安装来源 | Microsoft Edge 扩展商店 |
| 扩展 ID | odlomjlbamekndcpllcnffbgeohgkmjh |
二、先判断：究竟是哪一部分失效了？
仅凭“拒绝连接”，还不能直接判断是网络、登录状态，还是扩展本身出了问题。我和 Codex 一起做了两项检查。
1. 普通网页中的 ChatGPT 可以正常打开
在同一个 Edge 浏览器中，直接访问https://chatgpt.com/，能够正常加载 ChatGPT 界面，账号也处于登录状态。
这说明故障并没有表现为整个浏览器都无法访问 ChatGPT。但它还不能证明侧栏内的请求、重定向和权限检查也一定正常。
2. 桌面应用仍能通过扩展读取 Edge 标签页
通过浏览器控制接口，Codex 能够列出 Edge 中已打开的标签页。
因此，本次故障有一个很有用的定位线索：侧栏聊天界面加载失败时，浏览器控制通道至少仍有一部分功能正常。
这两条路径应当分开检查：
| 检查对象 | 本次结果 | 能说明什么 |
|---|---|---|
| Edge 普通标签页访问 ChatGPT | 正常 | 普通网页访问和当前登录状态可用 |
| 桌面应用通过扩展列出标签页 | 成功 | 浏览器控制通信至少部分可用 |
| 扩展侧栏加载聊天界面 | 失败 | 故障集中在侧栏页面加载路径 |
列出标签页成功，并不等于扩展所有功能都正常；但已经足以提醒我们，不应把“侧栏打不开”直接等同于“扩展完全断连”。
三、关键证据：侧栏控制台中的 CSP 报错
最初检查后台日志时，可以看到一次网络轮询失败，随后又出现了state: "recovered"。单独看这段日志，无法解释为什么侧栏一直打不开。
真正明确的证据，出现在侧栏页面的控制台里：
红色报错的内容是：
Framing 'https://chatgpt.com/' violates the following Content Security Policy directive: "frame-ancestors 'self' chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg chrome-extension://iaiigpefkbhgjcmcmffmfkpmhemdhdnj chrome-extension://lfkehkpjohcoelkpembgemeipeppanef". The request has been blocked.其中最关键的几个词是：
Framing ... violates ... frame-ancestors The request has been blocked.浏览器已经说明：它在尝试嵌入 ChatGPT 页面时，违反了当前生效的内容安全策略，因此阻止了加载。
如何找到侧栏的控制台？
如果也遇到这个问题，可以按下面的顺序检查：
- 点击工具栏中的 ChatGPT 扩展图标，保持报错侧栏打开。
- 打开
edge://extensions/。如果尚未显示“检查视图”，可启用扩展管理页的“开发人员模式”，用于查看调试入口。 - 找到 ChatGPT 扩展，查看“检查视图”中的页面链接。本次对应的是
codex-work-sidepanel.html。 - 点击侧栏页面链接，切到Console / 控制台，检查加载失败时的报错。
注意区分侧栏页面与旁边的“服务工作进程”。我最初看到的background.js日志，主要反映后台通信状态；它没有直接给出侧栏嵌入失败的原因。如果侧栏页面链接没有出现，可以保持侧栏打开后刷新扩展管理页，或者尝试在侧栏内部右键选择“检查”。
四、为什么 Edge 商店版会被拦截？
1. frame-ancestors 检查的是“谁在嵌入我”
CSP（Content Security Policy，内容安全策略）中的frame-ancestors指令，用来限制页面可被哪些祖先页面嵌入。当 iframe 的祖先来源不符合策略时，浏览器会阻止该页面加载。这里检查的不只是 iframe 的目标地址，还包括承载它的来源。W3C CSP 规范
可以用一个简化例子理解：
允许嵌入的来源：chrome-extension://扩展A的ID 实际发起嵌入： chrome-extension://扩展B的ID 结果： 来源不匹配，嵌入被阻止普通标签页直接打开网站，与扩展侧栏通过 iframe 嵌入网站，是两种不同的加载场景。这就解释了为什么“网页能打开”和“侧栏打不开”可以同时发生。
2. 两个商店版本对应不同的扩展来源
这次需要对比的是下面两个 ID：
| 扩展来源 | 扩展 ID | 是否出现在本次报错的允许名单中 |
|---|---|---|
| Chrome Web Store | hehggadaopoacecdllhhajmbjkdcmajg | 是 |
| Microsoft Edge 扩展商店 | odlomjlbamekndcpllcnffbgeohgkmjh | 否 |
这组 ID 的对应关系已与本地 OpenAI 浏览器插件随附的配置核对。Chromium 扩展使用chrome-extension://扩展ID形式的来源；因此，即使扩展名称同为 ChatGPT，两个不同 ID 仍然对应不同的来源。这些 ID 标识扩展，不是用户的账号 ID。Chrome 开发者文档
在我安装的版本中，实际扩展来源是：
chrome-extension://odlomjlbamekndcpllcnffbgeohgkmjh它没有出现在控制台显示的允许名单里。这是本次侧栏加载被 CSP 阻断的直接线索。
3. 能确认到哪里，还不能确认什么？
可以确认的是：这次失败确实触发了 frame-ancestors 检查，而报错策略没有列出本机 Edge 商店版扩展来源。
结合相同社区报告，产品的网页嵌入策略与 Edge 商店版扩展之间存在适配问题，是合理的判断。
但这次没有取得足以追溯配置来源的完整浏览器网络证据，也没有 OpenAI 服务端的配置记录。因此，还不能进一步断言是某次具体部署漏配、缓存策略过期，或某个版本切换导致了回归。
重新启动 Edge 后仍然失败，也符合这个现象：只要加载时仍然得到不匹配的策略，重新打开侧栏就会再次被拦截。
五、临时解决方案：在 Edge 中使用 Chrome 商店版官方扩展
临时办法是：在 Edge 中安装 Chrome Web Store 版本的官方 ChatGPT 扩展。
这个方案的依据是，Chrome 商店版扩展的来源已经出现在上述允许名单中。微软也明确支持在 Edge 中安装 Chrome Web Store 的扩展。微软官方安装说明
本机结果：安装 Chrome 商店版官方扩展后，ChatGPT 侧栏恢复正常，可以显示聊天界面。
操作步骤
- 打开
edge://extensions/，找到现有的 ChatGPT 扩展，确认其 ID 是odlomjlbamekndcpllcnffbgeohgkmjh，先关闭它的开关并保留安装。 - 使用Edge 浏览器打开 ChatGPT 的 Chrome Web Store 页面。
- 核对扩展名称、发布者 OpenAI，以及页面地址中的 ID
hehggadaopoacecdllhhajmbjkdcmajg。 - 按商店页面提示安装。如果 Edge 提示允许其他商店的扩展，以及新增扩展需要的权限，阅读并确认相应提示。
- 打开新安装的 ChatGPT 扩展，检查侧栏是否能够加载。
- 再从桌面应用检查 Edge 标签页读取或原先使用的浏览器功能是否正常。
这里使用的仍然是 Edge 浏览器，改变的是扩展的商店版本及其来源 ID。
修复结果与建议复查项
本次手动确认了侧栏界面恢复；恢复后的控制台日志及完整浏览器控制操作，尚未重新采集和复测。
其他读者操作时，仅看到“已安装”，还不足以判断故障解决。建议继续确认：
- 侧栏显示可用的 ChatGPT 聊天界面。
- 重新打开侧栏时，不再出现这条 CSP 拦截。
- 原先需要的桌面端浏览器功能仍可使用。
如果依然失败，应记录新的控制台错误，确认是否还是同一个原因；临时方案未生效时，也可以关闭新版本、重新启用保留的原扩展。
这是一种使用当前已允许来源的替代办法，不需要关闭浏览器的 CSP 检查。长期修复仍需要产品侧让嵌入策略与所支持的扩展版本保持一致，或者调整侧栏的加载方式。
六、向上游补充复现信息
截至 2026 年 10 月 16 日本文核对时，#54490 仍处于 Open 状态。另外一个相同报错的报告 #54503 已被标记为重复问题并关闭。
我已经在 #54490 的评论中补充了本机环境和三张截图。对同类故障，最有用的补充信息包括扩展来源与 ID、版本号、系统和浏览器版本，以及完整的 CSP 错误。
通过本文我们可以知道：
同一个扩展的界面加载与浏览器控制通信，可以分别成功或失败。先定位失败发生在哪一层，再找到对应页面的日志。
