[Windows] Chrome DiskCacheDir policy causes in-app browser blank pages and cache initialization hangs

What version of the Codex App are you using (From “About Codex” dialog)?

Windows MSIX package: 26.901.6511.0（从实际安装包核实，未把它冒充 About 对话框的显示版本）。
内置浏览器运行时报告 Chromium 152.0.7977.83。

What subscription do you have?

未提供；本报告未判断订阅是否相关。

What platform is your computer?

Windows NT 10.0.26200，x64。Codex 桌面应用运行在 Windows，开发工作区使用 WSL2。

What issue are you seeing?

Codex 侧边栏内置浏览器访问 http://localhost:8080/ 时，大多数情况下长期白屏或一直转圈，没有可见错误；偶尔可以加载。同一地址在应用外的浏览器中正常。

这台机器设置了系统级 Chrome 策略：

HKLM\Software\Policies\Google\Chrome
DiskCacheDir (REG_SZ) = Z:\TEMP\Chrome\

Z: 是内存盘，用于临时缓存。移除这一项策略并完整重启 Codex 后，页面恢复正常，HTTP 缓存初始化等待也消失。 没有修改业务服务或 Codex 安装包。尚未证明问题依赖内存盘介质，也没有在另一种磁盘上做同策略对照。

What steps can reproduce the bug?

以下是故障机器上的复现条件，并非已验证的全新用户配置最小复现：

1. 在 Windows 上设置上述 Chrome DiskCacheDir 策略，确保目标缓存目录可用。
2. 完整启动 Codex 桌面应用。
3. 在内置浏览器打开正常运行的 localhost:8080 Web 应用（页面使用外部 JS/CSS）。外部浏览器访问同一服务正常。
4. 观察内置浏览器白屏或持续加载。故障跨重启出现，也在新开的第二个 localhost 标签上出现；但不是每次尝试都失败。
5. 对照：备份并仅移除 DiskCacheDir 策略，完整退出并重启 Codex，再访问同一页面。该机器上恢复成功。

已有自定义 Chrome UserDataDir 策略在对照前后保持不变。本次验证没有删除 Cookies、站点存储或整个用户配置。

What is the expected behavior?

有效的缓存目录策略不应使不同浏览器配置共用冲突的缓存后端，从而无限等待。若无法初始化缓存，应提供明确错误或可用的降级处理，而不是无提示白屏。缓存清理也应能完成或返回可诊断的失败。

Additional information

已观测证据

原生启动 trace 同时包含两种配置路径（已省略用户目录前缀）：

…\Codex\web\Codex\codex-browser-app
…\Codex\web\Codex\Default\Partitions\codex-browser-app

两者末级名称相同。启用策略时，实际 trace 中的缓存访问位于：

Z:\TEMP\Chrome\codex-browser-app\Cache\Cache_Data
Z:\TEMP\Chrome\codex-browser-app\Code Cache\js
Z:\TEMP\Chrome\codex-browser-app\Code Cache\wasm

• 故障 NetLog 中，两个 localhost 导航请求均停在 HTTP_CACHE_GET_BACKEND BEGIN，没有对应 END；这些请求尚未进入 HTTP_TRANSACTION_SEND_REQUEST。
• 在一次独立诊断中重建 NetworkService 后，HTML/JS/CSS HTTP 下载可以完成，但页面仍白屏。因此下载完成本身不能作为页面恢复的证据。
• 另一次实际执行仅缓存的 clearBrowsingData({dataTypes:['cache'],timeRange:'allTime'}) 后，调用超过 370 秒仍 pending。History.ClearBrowsingData.Duration.SlowTasks180s 的未完成任务桶为 4、10，对应 kHttpCache、kCodeCaches。
• 更早也遇到过“清除浏览数据”选项窗口尚未打开就等待的现象；该设置查询后来已恢复。它与上面实际删除缓存的等待是不同阶段，不能混为一谈。
• 启动参数 --disk-cache-dir 指向新目录的早期实验没有实际切换缓存位置；Chrome 策略优先级解释了这一现象。

移除策略并完整重启后：

• 两个默认配置目录下分别出现 HTTP 与 JS 代码缓存索引。
• localhost 首页请求的 HTTP_CACHE_GET_BACKEND BEGIN/END 在同一毫秒内完成，约 5ms 完成首页响应。
• JS/CSS 请求正常完成。
• 用户确认页面正常显示；只读 DOM 检查确认 /login 的 document.readyState 为 complete。
• 修复后未再次测量缓存清理耗时；未重新启用策略做反向复现，也未做长期稳定性验证。

机制推断与证据边界

Chromium 上游 HTTP cache 和 generated-code cache 路径配置均有如下逻辑：设置 DiskCacheDir 后，以策略目录拼接原缓存路径的 BaseName。两个不同完整路径若末级同名，就可能映射到同一缓存目录。

BackendCleanupTracker 按缓存路径管理占用；同一路径已有后端时，后续创建会登记清理后的重试回调。该机制与观测到的初始化等待、清理等待及移除策略后的恢复一致。

这是有路径和对照证据支持的冲突假设，尚未捕获具体原生等待栈，不能声称已证明某把锁死锁。 偶发成功可能取决于初始化顺序和后端释放时机，历史成功现场未逐次捕获。仍需维护者确认问题属于 Codex 浏览器配置整合还是 Chromium 上游，并补充最小复现。

可优先检查：不同 browser context/storage partition 在策略生效后是否仍具有唯一的缓存目录，以及重复目录占用是否会让初始化回调无限等待。

参考：

• Chrome DiskCacheDir policy
• HTTP cache path mapping
• Generated-code cache path mapping
• BackendCleanupTracker
• Browsing data removal task identifiers

本报告由 Codex 协助整理，页面恢复由用户确认。仅发布脱敏后的技术摘要；未附原始 NetLog、原生 trace、页面内容、凭证、个人目录或业务代码。

Start with profile_network_context_service.cc and chrome_content_browser_client.cc to trace how DiskCacheDir maps HTTP and generated-code caches, then inspect net/disk_cache/backend_cleanup_tracker.cc and browsing_data_remover_impl.h. Reproduce with the policy enabled and compare browser contexts or storage partitions. Done means unique cache paths or safe handling, no indefinite HTTP_CACHE_GET_BACKEND or cache-clear waits, and a diagnostic failure or usable fallback.