C:\project

｜ 空气 能破，而且你这个现象我判断 八成不是“网页真的超时”，而是 Codex 的“等待条件”和肉眼看到的“页面已经打开”不是一回事。

最典型的是：页面已经渲染出来了，但后台还有 WebSocket、埋点、广告、流式请求、iframe 或 SPA 请求一直没结束，于是 Codex 还在等某个 load/network idle/navigation complete 条件，最后自己判“超时”。这类情况下，单纯把 timeout 从 30 秒改成 60/120 秒通常治标不治本。

我建议你直接这么处理。

第一步，打开：

ChatGPT/Codex 桌面版 → Settings → Browser → Developer mode → Enable full CDP access

官方现在明确提供这个模式，它让 Codex 通过 Chrome DevTools Protocol 直接检查 DOM、console、network、页面状态，而不是单纯靠“看网页 + 等页面加载结束”。

这个对你这种“肉眼已经打开，但 Agent 说超时”特别有用。

然后最关键的，是给 Codex 加一条网页操作规则。我建议你直接塞进你的项目指令 / AGENTS.md：

网页自动化容错规则：

1. 页面导航、goto、load、network-idle 或浏览器等待发生 timeout 时，不得立即判定网页打开失败。
2. timeout 后必须立即二次检查：
   - 当前 URL
   - 页面 title
   - document.readyState
   - 当前页面可见正文
   - 目标元素 / 目标文本是否已经存在
3. 如果页面已经显示、URL 已正确跳转、目标 DOM 或目标文字已经出现，则将该 timeout 视为“等待条件误报”，继续执行后续操作。
4. 优先等待具体的目标元素、按钮、文字或 DOM 状态，不要依赖 network idle 作为页面成功的唯一判定标准。
5. 对 SPA、动态网站、流式页面、WebSocket 页面，不要求网络完全静默。
6. 页面肉眼可见但自动化状态不确定时，优先通过 CDP 检查 DOM、console、network 和当前页面状态，再决定是否重试。
7. 禁止因为单次 navigation timeout 反复刷新整个网页。
8. 只有同时满足以下情况才判定真正失败：
   - 当前 URL 不符合预期；
   - 目标内容不存在；
   - DOM 无有效内容或页面明确报错；
   - 重试一次后仍无法进入目标状态。

这一段非常重要。你的核心不是：

“不要超时。”

而是：

“超时不能等同于失败。”

这是两个完全不同的东西。

比如 Codex 做：

打开 example.com/dashboard

结果可能是：

Navigation timeout exceeded

但实际上：

location.href = https://example.com/dashboard
document.readyState = interactive
页面已经出现 Dashboard
“创建项目”按钮也已经出现

那就应该直接继续点“创建项目”，而不是傻乎乎地：

页面加载失败 → 再打开一次 → 再刷新 → 又超时 → 任务失败。

你现在碰到的很可能就是这一类。

还有一个很实用的改法：把“等待页面完成”改成“等待我要操作的东西出现”。

例如不要：

进入页面
→ 等待 network idle
→ 点击登录

改成：

进入页面
→ 等待“登录”按钮出现
→ 按钮出现立即继续

再比如后台页面：

进入订单页
→ 等待订单表格 / “订单管理”标题

而不是：

进入订单页
→ 等整个网站完全停止网络通信

很多现代网站实际上永远不会真正 network idle。聊天网站、Notion、Google 系、后台管理系统、各种 React/Next.js 应用尤其明显。

还有一个你可以注意的地方：Codex 现在实际上有两种网页路线。

内置 Browser 有自己独立的浏览器状态；Chrome Browser Use 则可以利用你 Chrome 已有的登录状态、Cookie、标签页和扩展。官方也明确区分了这两种。

所以我的推荐是：

普通网页测试、localhost、你自己的网页 → 内置 Browser
已经登录过的网站、需要 Cookie、账号状态、Chrome 扩展 → Chrome Browser Use
网页状态识别老抽风 → 开启 Full CDP
遇到 timeout → 先检查 DOM/URL，而不是刷新

还有一个特殊情况你得留意一下。

如果你现在 Codex 项目是跑在 WSL 里面，比如：

/home/halo/project

而 Codex 桌面版又是 Windows 环境，那么最近确实有人报告过 Windows Codex Desktop + WSL 项目 + Browser Use 的运行时衔接问题，Browser Use 的 Windows 侧 runtime 和 WSL sandbox 路径会发生冲突。这个问题的症状不一定跟你完全一样，所以我不会直接认定就是它。

但你可以很简单排除：

如果同一个网页任务：

C:\project
D:\project

项目里稳定，

而：

/home/xxx/project

就疯狂超时/Browser Use 异常，

那就基本锁定 WSL 桥接层了。

所以如果让我给你一个最省事的方案：

开 Full CDP + 加上面那段“timeout ≠ failure”的规则 + 让它等待具体 DOM，而不是 network idle。

这三个一起上，往往比“把超时时间调到120秒”有效得多。