ChatGPT Work web silently loses agent-turn continuation around tool calls; external write may still commit

Product / surface

ChatGPT Work Mode in the web app, not Codex CLI or Codex Desktop.

Subscription

ChatGPT Plus

Client

• Windows 10 x64
• Firefox 153
• Long-running project conversation

Work runtime diagnostics

Collected from the active Work runtime after the interruption:

UTC probe: 2026-07-27T18:46:49Z
Kernel: Linux 6.12.13 x86_64
Container OS: Ubuntu 24.04.3 LTS
CODEX_PRIMARY_RUNTIME_BUNDLE_VERSION: 26.708.11517
Git: 2.51.1
Python: 3.12.13
Node: v24.14.0
Codex CLI in Work container: not installed
GitHub CLI in Work container: not installed

No readable Work turn logs or request ID were exposed in the permitted runtime paths. The session log location is access-restricted, so no attempt was made to bypass that boundary.

What issue are you seeing?

The Work agent intermittently loses the continuation of a turn around connector or tool boundaries. It has happened more than once in the same project conversation on 2026-07-27.

Two observed variants:

1. The agent emits a commentary message saying that the next tool action is starting, but the tool call never appears and the turn silently ends.
2. The external tool action succeeds, but the tool result, continuation, and final response never appear. The user has to send another message before the completed external action is discovered by readback.

There was no visible error banner, reconnect message, failed tool result, or final assistant response in these cases.

Strongest observed evidence

During a Notion write, the agent announced that it was publishing a reviewed plan. The turn then stopped without showing the write result or a final response.

A subsequent turn performed readback and confirmed:

Notion page creation time: 2026-07-27T18:30:40Z
Page body: complete
Kanban properties: present
Duplicate retry: not required
Readback latency: approximately 2 seconds

This separates external execution from conversation continuation: the connector mutation committed successfully, while the Work agent turn lost its post-tool continuation.

Steps to reproduce

The failure is intermittent, but the observed sequence is:

1. Open a long-running ChatGPT project conversation in Work Mode on Firefox.
2. Run a tool-heavy task involving several read-only connector calls followed by one external write.
3. Let the agent emit commentary immediately before the write.
4. Observe that the turn sometimes stops with no final response.
5. Send a follow-up message and read the target system.
6. In one occurrence, the external write is already committed even though its result never appeared in the conversation.

A second occurrence stopped one boundary earlier: after commentary and before the expected tool call appeared.

Expected behavior

After commentary, the planned tool call should start. After a successful tool result, the same agent turn should continue and return a final response.

If the turn is cancelled or disconnected, Work should show an explicit failure state and preserve enough identity to determine whether an external mutation committed before offering retry.

Actual behavior

The turn silently ends. Depending on the occurrence, either the expected tool call never appears or the external action commits without its result and continuation being delivered to the conversation.

This creates an idempotency risk: without a manual readback, the user cannot know whether retrying will duplicate the external write.

Related reports

• #28231 reports CLI conversation interruption after a successful command.
• #14142 tracks a broader core-agent-loop conversation interruption.
• #24475 reports conversation routing/state failures around reconnects and background agents.

This report is separate because it occurs in ChatGPT Work web and includes a confirmed connector commit followed by a lost continuation.

Additional diagnostic request

Could the team correlate server-side turn and connector logs around 2026-07-27T18:30:40Z for a Plus Work session using runtime bundle 26.708.11517? No request ID was exposed in the UI or accessible runtime state.