[Bug] v5.0.6 Zero Risk turn remains Working after successful native tool calls, then logs trusted environment unavailable

[korboybeats]

Codex Web GPT version

5.0.6

Platform

macOS arm64

ChatGPT account tier

Pro

Integration mode

Zero Risk / manual mode

Selected model

ChatGPT Web — Zero Risk Pro

What happened?

A long-running Zero Risk task can become permanently stuck in Codex even after the ChatGPT Temporary Chat has stopped generating.

Observed sequence:

1. Start a Codex task with ChatGPT Web — Zero Risk Pro.
2. Complete the normal manual Zero Risk flow (copy/paste prompt, select Codex Zero Risk, send, confirm Sent).
3. ChatGPT uses the native Codex harness normally.
4. Many native tool calls execute successfully (exec_command, write_stdin, etc.).
5. The ChatGPT Temporary Chat eventually stops generating and shows a final response.
6. The outer Codex task continues executing native tools afterward.
7. Eventually native tool activity stops.
8. Codex remains on Working indefinitely instead of completing.
9. The launcher then repeatedly logs:

[chatgpt-web] trusted environment unavailable
(thread_id=present, turn_id=present, previous_response_id=none,
 replay_prefix_items=0, context_messages=4)

The stuck turn does not resolve by itself and must be interrupted manually.

This happened more than once during the same session.

Reproduction evidence

One affected trace:

traceId=95876c4890c6

Relevant lifecycle from Launcher → Activity → Export safe log:

2026-09-14T12:58:11.875Z  broker trace=95876c4890c6 registered
2026-09-14T12:58:11.904Z  browser.manual_turn_started
2026-09-14T12:58:38.591Z  browser.manual_prompt_confirmed

The turn then successfully executed multiple native tool calls. Examples:

13:01:10  exec_command queued → delivered → completed
13:01:26  exec_command queued → delivered → completed
13:01:37  exec_command queued → delivered → completed
13:01:52  exec_command queued → delivered → completed
13:02:14  exec_command queued → delivered → completed
13:02:29  write_stdin queued → delivered → completed
13:03:06  exec_command queued → delivered → completed
13:03:38  exec_command queued → delivered → completed
13:03:45  exec_command queued → delivered → completed
13:04:18  write_stdin queued → delivered → completed

The shown broker claims were valid=true, and each tool call completed with pending=0.

Afterward, instead of the turn completing, the daemon began repeatedly reporting:

2026-09-14T13:11:27.321Z trusted environment unavailable
2026-09-14T13:11:27.560Z trusted environment unavailable
2026-09-14T13:11:27.993Z trusted environment unavailable
2026-09-14T13:11:28.801Z trusted environment unavailable
2026-09-14T13:11:30.377Z trusted environment unavailable
2026-09-14T13:11:33.313Z trusted environment unavailable

Additional repetitions occurred shortly afterward.

Eventually:

2026-09-14T13:35:19.483Z
browser.retained_tab_expired
traceId=95876c4890c6

I do not see a normal completion event for this trace between the successful tool work and retained-tab expiration.

Second similar occurrence

The same safe log contains another long Zero Risk trace:

traceId=507dcc8ce75c

It similarly:

• started successfully;
• reused the retained Temporary Chat;
• executed many native exec_command / write_stdin calls successfully;
• had the shown broker claims accepted with valid=true;
• later stopped making progress;
• was followed by repeated trusted environment unavailable warnings.

So this does not appear to be a one-off failed tool invocation.

Relation to #424

This looks related to #424 because the same trusted environment unavailable symptom appears on v5.0.6 after successful browser-side work.

However, this reproduction is Zero Risk/manual mode and I did not observe a compaction event around the affected trace in the exported safe log. That suggests the trusted-environment continuation/restoration failure may also affect ordinary Zero Risk turns, not only post-compaction continuation.

Expected behavior

Once the Zero Risk browser turn and native Codex harness are successfully bound:

• successful native tool activity should preserve the trusted Codex environment for the lifetime of the turn;
• a ChatGPT-side final response should not leave the outer Codex turn permanently running;
• if the bridge can no longer restore the trusted environment, the pending native turn should fail explicitly instead of remaining on Working indefinitely;
• already-completed tool work should remain committed;
• the user should not need to press Esc to recover.

Privacy-safe diagnostics

I captured Launcher → Activity → Export safe log before interrupting the stuck turn. I can provide the exported JSONL if needed.

Zero Risk/manual mode did not appear to create a local diagnostics/browser-turns directory on this installation, so I do not have per-turn browser checkpoint JSON for these traces.

Related issues

• [Bug] Post-compaction continuation fails with trusted environment unavailable on v5.0.6 after successful Bigger Context handoff #424 — same trusted environment unavailable symptom on v5.0.6, but specifically after remote compaction.
• [Bug] Submitted browser turn keeps calling a retired MCP binding #339 / [Bug] Pro full-mode: browser turn retired while ChatGPT still claims the token (confirms #274 on Pro/arm64; retry in the retained chat gives up; post-completion claims seen even on successful turns) #279 — related browser/native turn-lifetime and MCP ownership problems, although this reproduction does not show the same valid=false, retiredTurn=... pattern during the affected tool work.

Preflight checklist

• Reproduced on Codex Web GPT v5.0.6
• macOS arm64
• ChatGPT Pro
• Zero Risk / manual mode
• Native tool calls demonstrably succeeded before the stall
• Privacy-safe Activity export captured before manually interrupting the stuck turn
• Existing issues searched

[miuuyy]

Thanks for the timeline. Please attach the safe JSONL export you already captured, covering trace 95876c4890c6 from its start through the first trusted-environment error and the eventual interruption/expiry. I need to check whether codex_turn_complete was called and accepted, and how that lines up with the original Codex task ending or starting another turn. A final answer on the web page alone does not establish that handoff.

Please also confirm whether Bigger Context was enabled and whether compaction actually occurred. I will keep this separate from #424 unless the events establish the same path.

Please attach Launcher → Activity → Export safe log immediately after one reproduction. Drag the exported file into a reply here, or ZIP it if GitHub rejects the extension. Include the failure time/timezone. Do not post raw logs, credentials, full configuration, or private conversation/tool contents.

[korboybeats]

codex-web-gpt-diagnostics-2026-09-16.jsonl.zip

For trace 95876c4890c6:

• Trace registered: 2026-09-14T12:58:11.875Z
• Manual prompt confirmed: 12:58:38.591Z
• Native tool calls continued successfully through 13:04:18.478Z, with the broker calls completing at pending=0
• First trusted environment unavailable: 13:11:27.321Z
• The warnings then repeated
• Retained tab expired: 13:35:19.483Z
  I do not see a codex_turn_complete event or another normal completion event for this trace in the safe export.
  Bigger Context was disabled; this installation was configured with --standard-context.
  I do not see a compaction event during this trace. The compaction-related entries elsewhere in the export occurred at a different time and appear unrelated.
  Failure time: September 14, 2026 at 13:11:27 UTC (07:11:27 UTC-06).
  This is the Launcher → Activity → Export safe log only; no raw logs or private conversation/tool contents are included.

[oooing]

补充一个 Windows 上的相似复现（5.0.6，Zero Risk），供排查完成回传路径。症状与本 issue 相近，但我的安全日志没有出现 trusted environment unavailable，因此暂不认定根因相同。

环境与复现

• 平台：Windows；具体 OS/Codex 构建号尚未核实。
• 启动器运行时版本：日志明确显示 codex-chatgpt-web 5.0.6。
• 模式：Full harness + Zero Risk/manual。
• ChatGPT 账户：Pro；网页中选择 Pro。Codex 侧显示 ChatGPT Web — Zero Risk。
• 在原有 Codex 对话中切换到 Zero Risk 后，发送一个很小的只读任务：“列出当前工作目录里的文件，不修改任何内容。”
• 完成本轮手动粘贴、选择连接器、发送及启动器 Sent 确认。
• Codex 显示 Zero Risk connected，本地 exec_command 完成，ChatGPT 网页输出文件列表，但 Codex 仍停在运行/思考状态，没有收到最终答案。
• 尚未验证最新版或全新 Codex 任务能否复现；Bigger Context 设置未核实。较早的失败尝试截图出现过自动压缩，但无法据此认定下面这一轮发生了压缩。

同一轮安全日志时间线

以下摘自 Launcher → Activity → Export safe log，时间均为 2026-09-16 UTC（本地时区 UTC+8）。为保护隐私省略了 trace、request、tab、call 标识和私有路径：

01:50:22.903  browser.manual_turn_started
01:50:22.904  browser.manual_control_started
01:50:42.490  browser.manual_prompt_confirmed
01:51:01.733  broker claim received ... valid=true
01:51:22.021  broker claim received ... valid=true
01:51:22.023  queued ... tool=exec_command waiters=1
01:51:22.039  delivered calls=1 tools=exec_command
01:51:24.167  completed call=... pending=0
01:57:33.271  broker claim received ... valid=true
02:00:04.897  browser.manual_conversation_invalidated
02:03:34      doctor: ok=true; Responses proxy healthy;
              tunnel runtime healthy and ready

本地命令从排队到完成约 2.1 秒。导出日志未显示这一轮成功完成最终答案回传的记录，也未记录 manual_conversation_invalidated 的具体触发原因。诊断里的 connector warning 只是“本地检查无法证明连接器已挂载”，不是明确的连接失败。

此前另有三轮在约 30 秒的 sent-confirmation 阶段超时；上面这一轮已经确认 Sent 并执行了本地工具，应与前面未及时确认的问题区分。

手动请求完成回传后的网页反馈

当 Codex 仍在等待时，我在同一个 ChatGPT 网页对话中要求它使用原本的 request_id，通过 codex_turn_complete 把已有文件列表作为 final_answer 回传，不重新执行命令。

网页助手随后声称提交被拦截，并显示：

因 OpenAI 无法确定请求的安全状态，已拦截此工具调用。

证据边界：这段话来自网页助手的回复，不是已展开的原始工具错误；安全导出日志也没有包含该安全拒绝的原始内容。 因此不能仅据此认定是 OpenAI、连接器元数据还是其他层造成的拦截。可能与 #423 的安全检查症状相关，但本例是在本地工作已经完成后的最终回传阶段。

期望：最终答案能正常回到 Codex；若完成回传失败，应在 Codex 明确显示原因，而不是持续等待。请问还需要哪一类脱敏证据来区分“未调用完成工具”“完成调用被拒绝”和“完成已接收但未转发”？

以上仅发布安全日志的相关摘录；未上传完整配置、密钥、私人文件列表或聊天侧栏截图。