[Windows][Codex Desktop] Creating an in-app Browser Use tab exits the app after malformed PiP browser ID

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop: 26.707.3748.0 - Package: OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0 - Browser plugin/runtime build reported locally: 26.707.31428 - Codex CLI/app-server observed locally: approximately 0.144.0

What subscription do you have?

Pro $100

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop reproducibly exits to the desktop when Browser Use creates and
navigates a fresh in-app browser tab during an extensive, long-running task.

The original crash occurred during the active task. Restarting Codex and resuming
the affected thread were recovery steps necessitated by that crash—not the
original trigger.

After the thread was resumed and the browser operation was retried, the same
crash occurred again.

The Browser Use operation creates and navigates the tab successfully.
Immediately afterward, Codex receives Browser Use PiP metadata containing a
malformed-looking browser ID and logs a PiP upsert failure. The desktop
application then disappears without an error dialog.

Observed sequence

1. An extensive task is running in Codex Desktop.
2. The task creates a fresh in-app Browser Use tab and navigates it.
3. Codex Desktop exits without a crash dialog.
4. Codex is restarted and the interrupted thread is resumed so the task can

continue.

1. When Browser Use retries the tab operation, Codex Desktop exits again.
2. This occurred repeatedly across fresh application restarts.

Resuming the thread is therefore not established as the cause. It is part of the
recovery sequence following each crash.

What steps can reproduce the bug?

In the active Browser Use/Node REPL runtime, create and navigate a fresh in-app
browser tab:

globalThis.qaTab = await browser.tabs.new();
await qaTab.goto("http://localhost:8765/");

Observed result:

1. The in-app browser tab is created.
2. The page reaches http://localhost:8765/.
3. Browser Use sends PiP metadata.
4. Codex logs a PiP upsert failure.
5. The Codex Desktop application exits.

The latest recurrence used a reset Node REPL and a fresh browser backend, so the
failure is not limited to reusing a stale JavaScript tab handle.

What is the expected behavior?

The in-app browser tab should open and remain associated with the active thread.

If the browser session or PiP metadata is invalid, Codex should return a
recoverable browser error without terminating the desktop application or
interrupting the task.

Additional information

What actually happens?

The page opens, then the final two entries in the desktop log are:

2026-07-11T14:41:40.576Z info [browser-use-pip] Received Browser Use PiP metadata backend=iab browserID=-9a75-4483-8711-91f4b27b9229 tabID=1 threadID=<redacted>
2026-07-11T14:41:40.576Z warning [browser-use-pip] Failed to upsert Browser Use PiP content backend=iab tabID=1

There are no subsequent entries in that desktop log. The Codex window/process
disappears without displaying a crash dialog.

The browserID appears malformed because it begins with -9a75... rather than
a complete UUID.

Other occurrences also showed browser-session routing problems, including:

No ChatGPT browser route is available for browser session <redacted>

Reproducibility

Three observed crashes:

• The original crash during the active task.
• Two recurrences after restarting Codex and resuming the interrupted work.

In each case, the application exited in connection with the Browser Use tab/PiP
operation.

Restarting and resuming were necessary because of the preceding crash; they
should not be interpreted as prerequisites for the original failure.

I have not established that multiple concurrent threads, long thread history, or
thread resumption are required to reproduce the underlying Browser Use/PiP
failure.

Additional diagnostics

• No Windows Application/System crash event was recorded at the failure time.
• No Windows Error Reporting entry or Crashpad dump was found.
• No out-of-memory or resource-exhaustion evidence was found.
• The Browser Use operation completed before the desktop exited.
• The latest thread histories had balanced tool call/output pairs.
• Earlier crashes left orphaned tool calls in one thread. Those records were

repaired, but the Browser Use crash still recurred afterward. The orphaned
records were therefore crash aftermath or secondary corruption, not the
established trigger.

• After Browser Use was explicitly prohibited in the affected task, both

extensive threads could continue and pass resume smoke tests without another
desktop exit.

Suspected component

The evidence points to the Codex Desktop Browser Use PiP/session-routing path,
particularly its handling of an invalid or truncated browser ID when associating
a newly created IAB tab with the active thread.

The PiP upsert failure is the final logged event before application termination.

The logs establish a strong temporal association, but they do not contain a
native exception or stack trace proving which specific instruction terminates
the process.

Workaround

Do not invoke Browser Use, the in-app browser, browser.tabs, or Browser Use PiP
inside the affected task.

Using shell-based or static verification prevents the observed crash, but it
removes browser-based QA from the task.

Attachments available

I can provide privately:

• Sanitized excerpts from three separate crash logs.
• Exact timestamps and timezone.
• Affected thread IDs.
• Thread-state diagnostics.
• The complete logs if OpenAI provides a private upload location.

I am not attaching complete thread JSONL or unredacted application logs publicly
because they may contain local paths, repository details, prompts, or other
private information.