Browser Use IAB backend fails on multi-user macOS when shared temp socket path is owned by another user #21402

Activity

1. AaronRayRay

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on May 6, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   browser

   on May 6, 2026
3. camilohoyos commented on Sep 3, 2026

   

   camilohoyos

   on Sep 3, 2026

   More actions

   This is still reproducible in ChatGPT desktop 26.901.20858 (build 7658) on macOS 26.6.2 (25G83), arm64. It appears to be a recurring regression after desktop-app updates or first launch by another local administrator account.

   This is the same failure described in this issue, with a deterministic before/after result.

   Multi-version evidence

   • Original public report: 26.429.61741
   • Earlier independently confirmed occurrence on this shared Mac: 26.825.51511
   • Current independently confirmed occurrence: 26.901.20858 (build 7658)

   The local usernames are redacted below.

   State before repair

   Two local macOS administrator accounts use the same /Applications/ChatGPT.app installation. After the other account updated or launched the app, the shared runtime directory was:

   /private/tmp/codex-browser-use
   owner: <other-local-user>
   group: wheel
   mode:  drwxr-xr-x (0755)
   flags: none
   ACL:   none
   

   The active account could traverse the directory but could not create an entry in it. A direct write test failed with Permission denied.

   The newest ChatGPT app log then showed the causal backend error:

   browser_use_iab_backend_startup_failed
   backend=iab
   errorCode=EACCES
   errorMessage="listen EACCES: permission denied /tmp/codex-browser-use/<session>.sock"
   phase=native-pipe-startup
   release=26.901.20858
   

   The resulting user-visible symptom was that the built-in @Browser backend was not discovered. This is distinct from Safari or other app control through Computer Use, which can remain functional.

   Narrow repair and deterministic verification

   No sockets, browser profiles, home-directory data, Keychain items, cookies, history, or credentials were deleted or copied. The only repair was:

   sudo chown root:wheel /private/tmp/codex-browser-use
   sudo chmod 1777 /private/tmp/codex-browser-use

   After fully restarting ChatGPT:

   directory owner/group: root:wheel
   directory mode:        drwxrwxrwt (1777)
   active-user write test: PASS
   

   Fresh sockets appeared beneath the directory owned by the active macOS user. The post-restart log reported:

   browser-use native pipe listening pipePath=/tmp/codex-browser-use/<session>.sock
   browser_use_iab_backend_startup_ready backend=iab release=26.901.20858
   

   There were zero new EACCES or browser_use_iab_backend_startup_failed events after restart.

   End-to-end verification also passed: Codex detected the browser as Codex In-app Browser (iab), opened https://example.com, located the visible Learn more link from a screenshot, clicked it with the virtual mouse using screen coordinates, and navigated successfully to IANA's Example Domains page.

   Why this needs an application-level fix

   Random per-session socket filenames do not prevent the failure because every user still needs write access to the shared parent directory. Whichever local account creates /private/tmp/codex-browser-use first effectively determines whether later accounts can start the backend.

   The recurrence across multiple releases suggests the updater or startup path can recreate or leave this machine-wide directory as the invoking user with 0755, undoing the working state and causing first-user-wins behavior again.

   Please consider treating this as a desktop updater/startup and multi-user isolation bug. Durable options include:

   1. Use macOS's per-user $TMPDIR for the Browser IPC socket.
   2. Use a UID-scoped namespace with a private per-user child directory.
   3. If the fixed machine-wide parent is required, create and validate it as root:wheel 1777 on every relevant install/update/startup path, with safe handling of untrusted entries.

   A regression test should cover sequential and concurrent launches by two macOS users, including Fast User Switching and an app update performed by either account. A clearer UI error should also surface the underlying parent-directory permission problem instead of only reporting that no Browser backend was discovered.

   Security/privacy note: this was an availability failure; no evidence of cross-user access to browser profiles, credentials, cookies, history, or home-directory data was observed.
4. roryscot commented on Sep 29, 2026

   

   roryscot

   on Sep 29, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction extending this multi-user directory issue to the Chrome native host on macOS 26.6.2 (arm64), ChatGPT desktop 26.917.51856, Chrome extension 1.26.901.11451.

   Two macOS accounts had ChatGPT and Chrome running. In the affected account, the Chrome native-host manifest included the installed extension ID and pointed to an existing executable. The Chrome side panel showed Native transport disconnected, while Chrome's verbose log repeatedly printed extension-host: Operation not permitted (os error 1).

   At that point /private/tmp/codex-browser-use was owned by the other account with mode 0755. After that account closed ChatGPT and Chrome, the directory was empty but remained owned by that account. The other account renamed the empty directory to a backup (no deletion or permission change). The active path was recreated under the affected account, with an account-owned socket and running extension-host; the Chrome side panel then connected. No extension reinstall or privacy-toggle change was involved.

   A separate stale CODEX_CLI_PATH in the affected account's Codex config was corrected later. After restarting ChatGPT, the task runtime discovered both Chrome and the in-app browser and successfully read an existing Chrome tab. The Chrome side panel recovered before the CLI-path correction, so those two repairs should not be conflated.

   This before/after sequence strongly implicates cross-user ownership of the shared socket directory in this Chrome transport failure. We did not capture the exact syscall returning EPERM for the Chrome host, so that part remains an inference. It may explain at least one symptom like #42618. A per-user socket parent or explicit multi-user ownership handling would prevent the first-user-wins behavior.

   🚀React with 🚀1Reacted by humanitfest-bot
5. davidarny commented on Oct 13, 2026

   

   davidarny

   on Oct 13, 2026

   More actions

   Confirmed again on October 13, 2026, with ChatGPT/Codex Desktop 26.1007.30912 on macOS 27.0.1 (26A434), arm64. This also disables the first-party chat-management tools, including list_threads and read_thread.

   Two local macOS accounts use the same application installation. Before recovery, /private/tmp/codex-browser-use was owned by the other account with mode 0755. A direct Unix socket bind under that directory failed with errno 13 (Permission denied); the same test directly under /tmp succeeded.

   The desktop log showed this sequence:

   Failed to start the Codex app tools native pipe
   errorCode=EACCES
   errorMessage="listen EACCES: permission denied /tmp/codex-browser-use/<session>.sock"
   
   Codex app tools unavailable for this Core launch reason=missing-pipe
   
   mcp_extension_server_tools_empty
   pluginId=codex-app-tools@openai-bundled
   server=codex_app
   

   The affected chat's live tool catalog contained neither read_thread nor list_threads; tool discovery returned no matching tools.

   After changing the directory permissions to 1777 and fully restarting the application, both tools appeared. We then successfully called list_threads and used read_thread to read another existing chat. The directory still belonged to the other account, so changing ownership was not required for this recovery.

   Read-only inspection of the installed desktop bundle also matched the failure: the macOS socket parent is hard-coded to /tmp/codex-browser-use; directory setup calls recursive mkdir without validating existing write permissions. If native-pipe startup fails, CODEX_APP_TOOLS_PIPE_PATH is not set and the app-tools setup returns missing-pipe.

   Please include chat-management tool availability in the regression coverage for multi-user macOS startup. A per-user socket parent would avoid this cross-account permission conflict. The shared transport dependency also resembles #41404, although that report has a different trigger.

   👍React with 👍1Reacted by Mark Thomson