[macOS][26.715.72359] In-app browser crashes on site permissions; Duo local-network access remains denied

Open 💬 1 comment Opened Jul 23, 2026 by tfredricks
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

Codex Desktop / ChatGPT app 26.715.72359 (build 5718)

Bundled Chromium: 150.0.7871.124

What platform is your computer?

  • macOS 26.5.1 (25F80)
  • Apple Silicon / ARM64
  • Hardware model: Mac15,6

What issue are you seeing?

The Codex in-app browser cannot complete a Duo Desktop authentication flow that requires Local network access.

When the Duo page asks the user to allow Local network access, opening the site-information/settings page and changing that permission crashes the entire Codex app. The failure reproduced twice with the same native crash signature.

After relaunch, the Chromium partition preferences contain an allowed loopback_network content-setting entry for the redacted Duo origin (setting: 1). However, the active Duo page still reports all three permissions as denied through the Permissions API:

local-network-access: denied
local-network: denied
loopback-network: denied

The Duo page therefore continues to show “Allow local network access” and cannot communicate with Duo Desktop.

What steps can reproduce the bug?

  1. Open an enterprise SSO-protected site in the Codex in-app browser.
  2. Continue until redirected to a Duo Security prompt that uses Duo Desktop.
  3. Duo displays: “Allow local network access.”
  4. Click the site-information control and open the site-specific permissions page.
  5. Enable Local network access.
  6. Codex crashes.
  7. Relaunch Codex and repeat the sign-in flow.
  8. Observe that Duo still sees local-network permissions as denied.

The app logs show the in-app browser creating this internal settings page immediately before each crash:

chrome://settings/content/siteDetails?site=https%3A%2F%2F<redacted>.duosecurity.com

What is the expected behavior?

  • Opening site-specific permissions must not crash Codex.
  • Enabling Local network access should persist and become effective in the active in-app-browser partition.
  • Duo should be able to communicate with Duo Desktop and continue authentication.
  • A permission/settings failure should remain recoverable rather than terminating the app.

What actually happens?

Codex terminates with a native browser-main-process crash:

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000008
Termination Reason: SIGNAL, Code 11, Segmentation fault
Triggered Thread: CrBrowserMain / com.apple.main-thread
Top frame: v8::Isolate::LowMemoryNotification() + 38504

Two independent crash reports have the same signature. The crash is in the Codex/Chromium main process, not Duo Desktop.

Additional information

  • Workaround: use the normal Chrome browser instead of the Codex in-app browser.
  • Full .ips crash reports and local Codex logs are available privately if maintainers request them.
  • Raw reports are intentionally not attached publicly because the browser logs contain corporate SSO URLs, account identifiers, and temporary authentication parameters.
  • No credentials, corporate hostnames, or active authentication tokens are included in this issue.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 1 month ago

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

  • #33733

Powered by Codex Action