Windows浏览器窗口丢失后，重新加载会话无法访问

[S-Trespassing]

Windows 2.0.0，在手机上用浏览器访问由frp映射到公网的服务，有时候浏览器窗口丢失，再打开后opencodex会重新加载，重新加载后之前用的会话无法显示，只能让别的会话的codex重启opencodex解决

[RyensX]

是一直用OpenCodex访问会话吗？期间有没有Desktop去访问过？

[S-Trespassing]

@RyensX 只打开了codex desktop之后再没管,全程用opencodex访问会话,并且较容易出现该bug

[RyensX]

如果desktop完全不开，一直只用opencodex，会出现这种情况吗

[S-Trespassing]

这个倒没试过

[RyensX]

你有空可以先试试，如果还是存在问题，就把复现日志发我看看

[Evan-Joseph]

我这里也遇到了一个很接近的现象，补一组更具体的复现环境和脱敏日志，供定位参考。

环境：

• Host: macOS arm64
• OpenCodex: 2.0.1
• Codex Desktop: 26.611.62324, build 4028
• 访问方式: Cloudflare Tunnel public hostname -> 127.0.0.1:34054
• Client: 手机浏览器
• Auth: OpenCodex password auth，可以正常登录

现象：

登录认证成功后，可以进入 OpenCodex，也能看到历史会话入口。但是打开任意 /local/... 会话后，对话正文区域为空。看起来不是本地历史数据丢失，因为 gateway 日志里仍能看到 recentThreads 列表被推送出来；更像是移动端公网访问下某些会话加载请求/响应没有正确送达当前浏览器页面。

Cloudflared 侧脱敏日志摘要：

Request failed error="Incoming request ended abruptly: context canceled" dest=https://<opencodex-host>/api/ipc/invoke
Request failed error="Incoming request ended abruptly: context canceled" dest=https://<opencodex-host>/api/client-log
Request failed error="stream ... canceled by remote with error code 0" dest=https://<opencodex-host>/official-patched-v4/assets/thread-side-panel-tabs-....js
Request failed error="stream ... canceled by remote with error code 0" dest=https://<opencodex-host>/official-patched-v4/assets/composer-controller-....js

OpenCodex gateway 侧脱敏日志摘要：

[electron-message-handler] Failed to send message from view error={"name":"TypeError","message":"Failed to fetch","stack":"TypeError: Failed to fetch ... codex-bridge-polyfill.js ... invokeGatewayImmediate"}

[ws-hub] send_to_missing_client {"channel":"codex_desktop:message-for-view","type":"fetch-response","requestId":"...","clientId":"...","readyState":"missing"}

[official-ipc-route] ws_target_missing_for_ipc_response {"channel":"codex_desktop:message-for-view","requestId":"...","targetClientId":"...","payloadType":"fetch-response"}

一个可能的方向：浏览器刷新、切后台、弱网或移动端页面恢复后，旧的 clientId / WebSocket 连接已经失效，但 official runtime 的异步 fetch-response 仍尝试投递给旧 client，导致当前页面没有收到会话加载结果。最终表现就是 thread list 还在，但打开会话正文为空。

建议可以重点检查：

1. clientId -> WebSocket 映射失效后，是否需要让前端重建绑定并重新发起当前 thread 的加载请求。
2. 对 fetch-response / fetch-stream-* 这类 targeted message，如果目标 client missing，是否能降级为当前活跃 client 的重新请求机制，而不是直接丢弃。
3. 移动端从后台恢复或页面 reload 后，是否需要清理旧 pending request route，避免响应继续绑定旧 clientId。
4. 对 /local/... 深链进入会话时，如果初次 thread payload 没到达，前端是否可以显式 retry，而不是停在空正文状态。

README FAQ 里提到“第一次打开会话历史为空，稍等后刷新或重新进入”，但我这里在手机 + 公网 Tunnel 场景下刷新后仍可能复现，所以可能和移动端公网链路/WS 重连状态有关。

[RyensX]

我这里也遇到了一个很接近的现象，补一组更具体的复现环境和脱敏日志，供定位参考。

环境：

• Host: macOS arm64
• OpenCodex: 2.0.1
• Codex Desktop: 26.611.62324, build 4028
• 访问方式: Cloudflare Tunnel public hostname -> 127.0.0.1:34054
• Client: 手机浏览器
• Auth: OpenCodex password auth，可以正常登录

现象：

登录认证成功后，可以进入 OpenCodex，也能看到历史会话入口。但是打开任意 /local/... 会话后，对话正文区域为空。看起来不是本地历史数据丢失，因为 gateway 日志里仍能看到 recentThreads 列表被推送出来；更像是移动端公网访问下某些会话加载请求/响应没有正确送达当前浏览器页面。

Cloudflared 侧脱敏日志摘要：

Request failed error="Incoming request ended abruptly: context canceled" dest=https://<opencodex-host>/api/ipc/invoke
Request failed error="Incoming request ended abruptly: context canceled" dest=https://<opencodex-host>/api/client-log
Request failed error="stream ... canceled by remote with error code 0" dest=https://<opencodex-host>/official-patched-v4/assets/thread-side-panel-tabs-....js
Request failed error="stream ... canceled by remote with error code 0" dest=https://<opencodex-host>/official-patched-v4/assets/composer-controller-....js

OpenCodex gateway 侧脱敏日志摘要：

[electron-message-handler] Failed to send message from view error={"name":"TypeError","message":"Failed to fetch","stack":"TypeError: Failed to fetch ... codex-bridge-polyfill.js ... invokeGatewayImmediate"}

[ws-hub] send_to_missing_client {"channel":"codex_desktop:message-for-view","type":"fetch-response","requestId":"...","clientId":"...","readyState":"missing"}

[official-ipc-route] ws_target_missing_for_ipc_response {"channel":"codex_desktop:message-for-view","requestId":"...","targetClientId":"...","payloadType":"fetch-response"}

一个可能的方向：浏览器刷新、切后台、弱网或移动端页面恢复后，旧的 clientId / WebSocket 连接已经失效，但 official runtime 的异步 fetch-response 仍尝试投递给旧 client，导致当前页面没有收到会话加载结果。最终表现就是 thread list 还在，但打开会话正文为空。

建议可以重点检查：

1. clientId -> WebSocket 映射失效后，是否需要让前端重建绑定并重新发起当前 thread 的加载请求。
2. 对 fetch-response / fetch-stream-* 这类 targeted message，如果目标 client missing，是否能降级为当前活跃 client 的重新请求机制，而不是直接丢弃。
3. 移动端从后台恢复或页面 reload 后，是否需要清理旧 pending request route，避免响应继续绑定旧 clientId。
4. 对 /local/... 深链进入会话时，如果初次 thread payload 没到达，前端是否可以显式 retry，而不是停在空正文状态。

README FAQ 里提到“第一次打开会话历史为空，稍等后刷新或重新进入”，但我这里在手机 + 公网 Tunnel 场景下刷新后仍可能复现，所以可能和移动端公网链路/WS 重连状态有关。

看起来很像是ws广播阻塞了，在刷新后第一次打开会话数据是比较多的（官方行为）

你可以尝试一下下面2个操作告诉我结果:

1. 局域网手机访问，看看是否出现现在问题
2. 远程手机访问，在打开第一个会话后10秒去打开别的会话看看是否加载出来

[Evan-Joseph]

补充一下上面第 2 点的远程手机测试结果，有一个新现象比“始终为空”更准确：

• 现在暂时没有局域网手机测试条件，所以第 1 点还没法验证。
• 远程手机访问，路径是 public hostname -> Cloudflare Tunnel -> 127.0.0.1:34054。
• 打开第一个历史会话后，正文区域为空。
• 等了约 10 秒后再打开另一个历史会话，当时也还是空。
• 但随后把手机浏览器切到后台，再切回来，历史内容加载出来了。

这说明后端读历史大概率不是失败，而是前端在当前页面生命周期/WS 状态下没有及时把已经返回的数据应用到 UI。切后台再回来可能触发了 visibility/focus、WS reconnect、重新请求或状态 flush。

同一时间窗口的 OpenCodex gateway 里能看到这两个历史会话的请求都成功 routed：

[AppServerConnection] response_routed ... conversationId=019ec50e-4622-7600-b638-deaaf237a47b ... method=thread/read ... errorCode=null ... targetDestroyed=false
[AppServerConnection] response_routed ... conversationId=019ed96a-f246-75f2-914d-d33cee72c7f5 ... method=thread/read ... errorCode=null ... targetDestroyed=false
[AppServerConnection] response_routed ... conversationId=019ec50e-4622-7600-b638-deaaf237a47b ... method=thread/resume ... errorCode=null ... targetDestroyed=false
[AppServerConnection] response_routed ... conversationId=019ed96a-f246-75f2-914d-d33cee72c7f5 ... method=thread/resume ... errorCode=null ... targetDestroyed=false

同一窗口还看到 WS 相关异常：

[gateway:err] [2026-06-18T14:29:47.071Z] [ws-hub] upgrade_rejected_auth {"url":"/ws"}

cloudflared:
2026-06-18T14:29:47Z ERR Request failed error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: EOF" dest=https://<opencodex-host>/ws type=ws
2026-06-18T14:29:55Z ERR Request failed error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: EOF" dest=https://<opencodex-host>/ws type=ws

所以现在更像是：移动端远程访问时，初次进入历史会话的数据请求已经完成，但当前 renderer 没有及时消费/渲染；浏览器 background/foreground 后触发了某种恢复流程，内容才显示。建议可以重点看一下：

1. mobile browser 的 visibilitychange / focus 恢复时，是否触发了重新绑定 WS 或重新读取 active thread。
2. /ws 认证或重连失败后，当前页面是否会卡在旧 client/session 状态里。
3. thread/read 成功后，如果 UI 仍是空线程，前端是否需要一个显式 retry / state reconcile。

[RyensX]

补充一下上面第 2 点的远程手机测试结果，有一个新现象比“始终为空”更准确：

• 现在暂时没有局域网手机测试条件，所以第 1 点还没法验证。
• 远程手机访问，路径是 public hostname -> Cloudflare Tunnel -> 127.0.0.1:34054。
• 打开第一个历史会话后，正文区域为空。
• 等了约 10 秒后再打开另一个历史会话，当时也还是空。
• 但随后把手机浏览器切到后台，再切回来，历史内容加载出来了。

这说明后端读历史大概率不是失败，而是前端在当前页面生命周期/WS 状态下没有及时把已经返回的数据应用到 UI。切后台再回来可能触发了 visibility/focus、WS reconnect、重新请求或状态 flush。

同一时间窗口的 OpenCodex gateway 里能看到这两个历史会话的请求都成功 routed：

[AppServerConnection] response_routed ... conversationId=019ec50e-4622-7600-b638-deaaf237a47b ... method=thread/read ... errorCode=null ... targetDestroyed=false
[AppServerConnection] response_routed ... conversationId=019ed96a-f246-75f2-914d-d33cee72c7f5 ... method=thread/read ... errorCode=null ... targetDestroyed=false
[AppServerConnection] response_routed ... conversationId=019ec50e-4622-7600-b638-deaaf237a47b ... method=thread/resume ... errorCode=null ... targetDestroyed=false
[AppServerConnection] response_routed ... conversationId=019ed96a-f246-75f2-914d-d33cee72c7f5 ... method=thread/resume ... errorCode=null ... targetDestroyed=false

同一窗口还看到 WS 相关异常：

[gateway:err] [2026-06-18T14:29:47.071Z] [ws-hub] upgrade_rejected_auth {"url":"/ws"}

cloudflared:
2026-06-18T14:29:47Z ERR Request failed error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: EOF" dest=https://<opencodex-host>/ws type=ws
2026-06-18T14:29:55Z ERR Request failed error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: EOF" dest=https://<opencodex-host>/ws type=ws

所以现在更像是：移动端远程访问时，初次进入历史会话的数据请求已经完成，但当前 renderer 没有及时消费/渲染；浏览器 background/foreground 后触发了某种恢复流程，内容才显示。建议可以重点看一下：

1. mobile browser 的 visibilitychange / focus 恢复时，是否触发了重新绑定 WS 或重新读取 active thread。
2. /ws 认证或重连失败后，当前页面是否会卡在旧 client/session 状态里。
3. thread/read 成功后，如果 UI 仍是空线程，前端是否需要一个显式 retry / state reconcile。

收到，你发的东西很有用，我找时间处理一下。另外如果你这边也有相关修复代码的话也可以提PR，比较好复现和处理

[Evan-Joseph]

收到，感谢佬跟进。

我这边目前还没有能直接提交 PR 的修复代码，主要是先把公网 / 移动端场景下的复现现象和日志尽量补齐，避免在没有稳定定位前乱改。后面如果我能把问题收敛到更小的复现场景，或者看代码时有比较明确的修复点，会继续补充，必要时也会尝试提 PR。

另外也想反馈一下，OpenCodex 实际用起来已经很不错。尤其是对主要使用第三方 API 服务、没有官方 OpenAI 账号体系可依赖的用户来说，它把 Codex Desktop 的本地会话能力延伸到了手机和远程访问场景。通过 Cloudflare Tunnel 之后，能在公网侧查看历史会话、继续跟进本机 Codex 工作流，这个体验很有价值。

再次感谢佬维护这个项目。

[RyensX]

收到，感谢佬跟进。

我这边目前还没有能直接提交 PR 的修复代码，主要是先把公网 / 移动端场景下的复现现象和日志尽量补齐，避免在没有稳定定位前乱改。后面如果我能把问题收敛到更小的复现场景，或者看代码时有比较明确的修复点，会继续补充，必要时也会尝试提 PR。

另外也想反馈一下，OpenCodex 实际用起来已经很不错。尤其是对主要使用第三方 API 服务、没有官方 OpenAI 账号体系可依赖的用户来说，它把 Codex Desktop 的本地会话能力延伸到了手机和远程访问场景。通过 Cloudflare Tunnel 之后，能在公网侧查看历史会话、继续跟进本机 Codex 工作流，这个体验很有价值。

再次感谢佬维护这个项目。

感谢支持！其实你提到的这种体验，也是我一开始做这个项目的目标。不过我并未使用tailscale/cft这类产品，主要是结合公司的高速VPN，所以比较难发现你遇到的这个问题😂