codex - 💡(How to fix) Fix Codex Desktop heartbeat automations fail Browser Use with 'Browser turn does not belong to this IAB pipe' [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#21422Fetched 2026-05-07 03:40:19
View on GitHub
Comments
2
Participants
2
Timeline
6
Reactions
0
Author
Timeline (top)
labeled ×4commented ×2

Error Message

  • fail earlier with a clearer unsupported-mode error instead of the ownership mismatch.
RAW_BUFFERClick to expand / collapse

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

Version 26.429.61741

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

Codex Desktop Browser Use works in a foreground user turn, but fails in a heartbeat automation turn with:

Browser turn does not belong to this IAB pipe

This is not the same failure mode as "No Codex IAB backends were discovered".

In the reproduced session, the initial user turn successfully opened https://www.google.com/ through Browser Use, and the automation heartbeat turn later failed immediately when running the same Browser Use flow.

I also verified through the app's Chromium DevTools Protocol target that a runtime turn/started capture shim did record the failing heartbeat turn id, so the failure is not just "no turn/started event reached the renderer". The remaining problem appears to be heartbeat / in-app-browser ownership validation for the current turn_id.

What steps can reproduce the bug?

  1. In Codex Desktop on macOS, start a thread and use [$browser-use:browser] to open https://www.google.com/.
  2. Confirm the foreground turn succeeds.
  3. In the same thread, create a heartbeat automation that runs daily with instructions to open https://www.google.com/ in the in-app browser and verify the final URL and title.
  4. Let the heartbeat run.
  5. Observe that the Browser Use JS call fails immediately with: Browser turn does not belong to this IAB pipe

Concrete reproduced session data:

  • Thread: 019dff3e-2f7a-7d43-91f9-d5e8728dccfb
  • Foreground success turn: 019dff3e-2f97-7093-8907-a4d7bfdd122f
  • Heartbeat failure turn: 019dff3f-2be9-70b2-a719-14e3f5dd40df

Foreground Browser Use call succeeded and returned:

{"url":"https://www.google.com/","title":"Google"}

Heartbeat Browser Use call failed in about 5ms with:

Browser turn does not belong to this IAB pipe

What is the expected behavior?

A heartbeat automation in the same thread should be able to use Browser Use against the in-app browser when the initial foreground thread already succeeded.

If heartbeat turns are intentionally isolated from the interactive IAB pipe, Codex should either:

  • create a valid Browser Use route for the heartbeat turn, or
  • fail earlier with a clearer unsupported-mode error instead of the ownership mismatch.

Additional information

The issue appears related to Browser Use route ownership / turn authorization in the desktop app.

Relevant observations:

  • turn/completed releases the Browser Use route.
  • A local runtime shim confirmed the failing heartbeat turn was seen at turn/started.
  • Even with the heartbeat turn captured, Browser Use still rejected the heartbeat turn_id for the IAB pipe.
  • This suggests the remaining bug is not only route capture, but the heartbeat turn's authorization against the selected in-app-browser session / owner.

Potentially related but different issue:

  • #19766 Codex Desktop Automations cannot use Browser Use plugin

That issue describes No Codex IAB backends were discovered, while this report is specifically about Browser turn does not belong to this IAB pipe after the browser path already worked in the same thread.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING