Windows: pausing Goal Mode still injects a continuation; restoring its in-app browser silently closes Codex

Start by reproducing the pause/resume sequence and reviewing the sanitized desktop logs and saved JSONL task-state evidence. Trace Goal Mode pause handling, interrupted task lifecycle restoration, and Browser Use webview recovery; done means pausing prevents continuation, interrupted tasks have balanced state, and stale browser restoration fails recoverably instead of closing the app.

What version of the Codex App are you using?

• Microsoft Store package: OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0
• Package status: Ok

What platform are you using?

Windows x64, native PowerShell/Codex Desktop.

What happened?

A long-running Goal Mode task repeatedly causes Codex Desktop to silently close/restart when its in-app browser session is restored. Pausing the goal does not fully stop the sequence: the persisted task record shows the goal becoming paused, followed immediately by another internal goal-continuation prompt in the same interrupted turn.

There is no corresponding Windows Application Error / Application Hang event for these closes and no Crashpad report. The Codex desktop log simply stops, followed by a fresh main-process session.

This appears to be an interaction among:

1. Goal Mode pause/continuation state,
2. interrupted or orphaned task lifecycle records,
3. thread resume restoring an in-app-browser webview, and
4. renderer/main-process termination without a recoverable error page.

Reproduction sequence observed

1. Run a long-lived Goal Mode task that uses Browser Use against a local frontend.
2. Reload/reopen Codex while the task has interrupted history.
3. Pause Goal Mode.
4. Codex persists status: "paused", but an internal Continue working toward the active thread goal prompt is recorded immediately afterward.
5. The task restores its Browser Use sidebar/webview and navigates to http://127.0.0.1:3000/.
6. Codex silently closes/restarts.
7. Reopening the same task repeats the browser restoration and close.

Sanitized timeline from the latest occurrence

2026-07-17T05:58:21.051Z event_msg task_started turnId=<redacted>
2026-07-17T05:58:27.407Z event_msg thread_goal_updated status=paused
2026-07-17T05:58:28.095Z response_item user <codex_internal_context source="goal"> Continue working toward the active thread goal...
...
2026-07-17T05:58:58.943Z IAB_TAB_ANALYTICS browser tab lifecycle action=opened
2026-07-17T05:58:59.263Z renderer created browser sidebar webview initialUrl=about:blank
2026-07-17T05:58:59.347Z runtime attached browser sidebar webview guestWebContentsId=2
2026-07-17T05:58:59.908Z browser sidebar dom-ready url=http://127.0.0.1:3000/
2026-07-17T05:59:00.397Z final line in desktop log
2026-07-17T05:59:16 local package creates a new Codex main-process log session

Two earlier app sessions ended with the same affected task restoring the same Browser Use webview and loading 127.0.0.1:3000 immediately before their logs stopped.

Saved task-state evidence

The affected rollout is valid JSONL but unusually large (about 71 MB) and has unbalanced lifecycle counts:

task_started:  193
task_complete: 187
turn_aborted:    1

The most recent task_started has no matching task_complete. Several earlier Goal Mode turns are also unmatched after previous silent closes.

On resume, the desktop log reports the latest turn as interrupted while still setting the task to streaming:

latestTurnStatus=interrupted markedStreaming=true

Additional startup signal

During one restart, bundled-browser-plugin reconciliation also attempted to uninstall/reconcile browser@openai-bundled and failed with:

failed to remove existing plugin cache entry: Access is denied. (os error 5)

The browser plugin subsequently loaded, so this may be secondary, but it could contribute to stale Browser Use state.

Expected behavior

• Pausing Goal Mode should prevent further automatic goal-continuation prompts.
• An interrupted turn should be persisted or synthesized as interrupted/failed with a balanced lifecycle.
• Restoring a thread with a stale Browser Use session should either restore cleanly or discard the stale browser route.
• A renderer/webview failure should show a recoverable error instead of silently closing the desktop app.

Actual behavior

• A goal continuation remains after the goal is persisted as paused.
• The task remains lifecycle-unbalanced and is resumed as streaming despite being interrupted.
• Restoring its in-app browser repeatedly correlates with silent app termination.
• Windows and Crashpad do not record a conventional application crash.

Related issues

• #23814 — repeated silent Windows app closes with interrupted turns restored as streaming and Browser/sidebar churn
• #23035 — interrupted/orphaned task lifecycle poisons thread reopen

This report is intentionally sanitized. Raw SQLite logs and the full rollout contain prompts, project names, local paths, and tool output, but targeted excerpts can be provided privately if requested.