Repository navigation
Remote SSH IAB route appears only after opening the same thread in the remote Linux GUI #44782
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Codex App 26.901.51231 (bundled Codex CLI 0.153.4)
What subscription do you have?
Not disclosed.
What platform is your computer?
Client: macOS Codex App using Remote SSHRemote execution host: Ubuntu 24.04, x86_64, with the Codex Linux GUI installed
What issue are you seeing?
An IAB backend is not available to a Remote SSH-backed thread until the exact same thread is opened once in the Codex GUI on the remote Linux host.
Before opening the thread in the remote-host GUI, browser discovery returns no IAB backend and direct lookup reports that iab is unavailable. Opening the same thread in the remote-host GUI reports already has an active writer, because the macOS client still owns the active thread. Despite that error, retrying from the original macOS Remote SSH thread immediately discovers the Ubuntu-hosted IAB and can navigate a public test page.
Closing or restarting the Codex GUI on the remote host removes the route and makes IAB unavailable again.
What steps can reproduce the bug?
- Install and run the Codex Linux GUI on an Ubuntu desktop host.
- From Codex App on macOS, connect to that Ubuntu host using Remote SSH and open a thread backed by the remote host.
- After a fresh restart of the Ubuntu Codex GUI, do not open that thread in the Ubuntu GUI.
- In the macOS Remote SSH thread, ask Codex to open a public URL with the in-app browser.
- Observe that no session-owned IAB backend is available.
- In the Ubuntu Codex GUI, open the exact same thread. The GUI reports that the thread already has an active writer.
- Leave the macOS thread open and retry the IAB request there.
- Observe that the Ubuntu-hosted IAB is now available and can navigate the public URL.
- Restart the Ubuntu Codex GUI and retry; IAB is unavailable again until step 6 is repeated.
What is the expected behavior?
If host-side IAB is supported for a Remote SSH-backed thread, the route should be initialized without requiring the same thread to be opened in a second GUI. If this topology is unsupported, IAB should be capability-gated with a clear explanation. Opening a thread in another GUI, especially when resume fails because of the active-writer lock, should not silently change browser availability for the original thread.
Additional information
No response
Activity
EthicalAIExplorer commentedon Oct 9, 2026
Adding a similar observation from Ubuntu 24.04.5 on 2026-10-09. The installed ChatGPT package was 26.1002.52244; the running app version was not independently verified. This used a dot-created task on a connected Linux desktop, rather than the macOS-to-Linux Remote SSH setup described above.
apps: []andbrowsers: [], andiabwas unavailable. A directly opened desktop session could use IAB.Opening the task, sending the direct prompt and elapsed readiness time were not tested separately, so the recovery trigger remains unconfirmed. Could this be another instance of session-owned IAB route initialization depending on the task being displayed in the GUI?
Related cross-platform observations, with different task topologies:
iabunavailable andapps=[]/browsers=[], despite successful preceding children. The exact desktop build was not captured.These are related operational symptoms; a shared cause has not been established. Our Linux observation does not reproduce the Windows sandbox error 32 / runtime ACL-validation failure in #52420.