[Bug][macOS] Bundled Bun 1.3.14 exits with SIGTRAP after connection reset and TLS verification failures

[RanceLee233]

Client or integration

Codex App

Area

Service lifecycle

Summary

OpenCodex 2.11.1 went offline twice without an ocx stop command. In both cases, the bundled Bun process terminated with a native EXC_BREAKPOINT / SIGTRAP on its main thread shortly after a connection reset followed by TLS certificate verification failures.

After the second crash, the page opened by ocx gui also became unreachable because the dashboard was served by the same terminated process.

Expected behavior: a transient upstream connection/TLS failure should fail or retry the affected request while the proxy stays alive, or at minimum exit with an actionable OpenCodex error. It should not terminate the entire proxy with a native trap.

Reproduction

The issue is intermittent rather than deterministically reproducible. The observed sequence was:

1. Run OpenCodex 2.11.1 on macOS arm64 and use Codex through the proxy for sustained traffic.
2. Open the dashboard with ocx gui. When no live proxy exists, this starts the proxy in the background.
3. During a period of network instability, an established upstream connection is reset.
4. OpenCodex retries; the retry fails with unknown certificate verification error.
5. The next request also fails certificate verification.
6. About 0.5–0.6 seconds later, the bundled Bun process exits with SIGTRAP.
7. The proxy and dashboard both become unreachable and are not restarted.

This happened twice with the same Bun image UUID, matching main-thread stack offsets, and matching instruction bytes.

Observed timeline (Asia/Shanghai, UTC+8):

• 16:43:47: consecutive TLS verification failure
• 16:43:48.062: Bun PID 61320 crashes with SIGTRAP
• 16:49:33: ocx gui is run and starts a new proxy process
• 17:26:28: consecutive TLS verification failure
• 17:26:29.187: Bun PID 66546 crashes with the same signature
• 17:28:30: ocx stop appears in shell history, after the crash; it did not cause the outage

There was no OpenCodex launchd service installed, so the detached process was not supervised or restarted after the native crash.

Version

2.11.1

Bundled Bun: 1.3.14

Operating system

macOS 26.5.2, Apple Silicon (arm64)

Provider and model

OpenAI Responses API; observed across multiple GPT models, including gpt-5.6-sol and gpt-5.6-luna.

Logs or error output

# Crash report 1
Report: bun.exe-2026-08-10-164349.ips
Launch: 2026-08-10 15:08:01 +0800
Crash:  2026-08-10 16:43:48.062 +0800
Exception: EXC_BREAKPOINT (SIGTRAP)
Termination: Trace/BPT trap: 5
Faulting thread: main thread

# Crash report 2
Report: bun.exe-2026-08-10-172630.ips
Launch: 2026-08-10 16:49:34 +0800
Crash:  2026-08-10 17:26:29.187 +0800
Exception: EXC_BREAKPOINT (SIGTRAP)
Termination: Trace/BPT trap: 5
Faulting thread: main thread

# Same bundled Bun image in both reports
Image UUID: c7e7a979-f99b-3466-9ad6-e56a63373a35
Matching top image offsets: 52255300, 52218912, 15551472

# Upstream failure sequence immediately before each crash
connection reset
retry attempted
unknown certificate verification error
next fetch: unknown certificate verification error
native Bun SIGTRAP approximately 0.5–0.6 seconds later

The crash was not a normal shutdown or an apparent macOS Jetsam/OOM termination: both reports record a native SIGTRAP, not SIGKILL, and there was no matching Jetsam report. OpenCodex's JS crash log was not written, which is consistent with a native runtime crash bypassing JS error handling.

Screenshots and supporting files

The complete macOS .ips reports are available locally and can be provided after redaction if maintainers need them. They are not attached initially because they may contain local filesystem paths and process metadata.

Additional observations:

• The two crashes have an identical native signature.
• A comparison of OpenCodex 2.10.2 and 2.11.1 found the same bundled Bun version (1.3.14) and no relevant change in the upstream retry path, so this may be a pre-existing runtime/transport issue exposed by network instability rather than a confirmed 2.11.1 regression.
• The dashboard failure is a consequence of the proxy process crash, not a separate browser failure.

Redacted configuration

{
  "port": 10100,
  "codexAutoStart": true
}

The requests used a local system HTTP(S) proxy. Provider credentials, account data, request bodies, and conversation content have been removed.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[Ingwannu]

Thanks for separating the dashboard consequence from the native crash. The two matching SIGTRAP signatures make this credible, but the excerpt is not enough to attribute the trap to an OpenCodex JavaScript path instead of the Bun TLS or system-proxy stack.

Please attach redacted excerpts from both .ips reports containing:

• exception and termination metadata;
• the complete faulting main-thread frame list;
• the Bun entry from usedImages or Binary Images, including UUID and load address;
• process, architecture, and OS build metadata.

Please also state which proxy mechanism was active (macOS system proxy or PAC, HTTP_PROXY or HTTPS_PROXY, or a local proxy), whether it intercepts TLS or installs a custom CA, and whether the same workload has ever crashed with that proxy disabled. Redact usernames and local paths, but keep image offsets and library names unchanged.

With those frames we can compare or symbolicate the two crashes and determine whether there is an OCX call site to isolate. Marking this as needs-info and leaving it open.