Codex Desktop heartbeat automations fail Browser Use with 'Browser turn does not belong to this IAB pipe'

[friuns2]

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:

• Codex Desktop Automations cannot use Browser Use plugin #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.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Codex Desktop Automations cannot use Browser Use plugin #19766

Powered by Codex Action

[friuns2]

Follow-up from local debugging of the concrete thread in this report.

The heartbeat failure in thread 019dff3e-2f7a-7d43-91f9-d5e8728dccfb matches the route-mismatch diagnosis in #20678 more closely than a missing-IAB-backend startup problem:

• foreground Browser Use turn succeeded: 019dff3e-2f97-7093-8907-a4d7bfdd122f
• heartbeat turn failed: 019dff3f-2be9-70b2-a719-14e3f5dd40df
• JSONL shows the Node REPL Browser Use call failed immediately with Browser turn does not belong to this IAB pipe
• a renderer CDP shim did observe the heartbeat turn/started, so the remaining rejection is in app-side Browser Use route ownership validation, not simply a missing renderer notification

I locally patched an extracted app bundle with the same shape as the #20678 workaround:

1. renderer captures Browser Use route on turn/started
2. renderer re-captures after turn/steer returns a turn id
3. main process resolves/authorizes Browser Use with exact (conversationId, turnId) first, then falls back to an active route for the same conversation/window

That keeps the conversation/window ownership boundary but removes the brittle exact-turn dependency that appears to break heartbeat and synthesized-turn cases.