Client or integration
OpenCodex dashboard
Area
Proxy and routing
Summary
Summary
After upgrading from 2.9.x → 2.10.2, the proxy child process crashes ~18s after start with exit code -1073740791 (0xC0000409 = STATUS_STACK_BUFFER_OVERRUN). Downgrading back to 2.9.1 makes it stable again. Both versions bundle the same Bun 1.3.14, so this is a regression introduced in the 2.10.x line, not a Bun runtime issue.
Environment
- OpenCodex (crashing): 2.10.2
- OpenCodex (stable): 2.9.1
- Bundled Bun (both): 1.3.14
- Node: v24.14.1 (nvm) — OpenCodex runs on bundled Bun, not Node
- OS: Windows 11 25H2 (build 26200.8246; registry ProductName misreports "Windows 10 Home China", UBR 8246)
- Arch: x64
- Antivirus: 火绒 (Huorong) — disabled during testing, crash persists → not AV-related
Reproduction (on 2.10.2)
- npm install -g --allow-scripts=bun @bitkyc08/opencodex@2.10.2
(the --allow-scripts=bun flag is REQUIRED — without it the bundled Bun postinstall is skipped; verify bun.exe is ~90MB, not a few hundred bytes)
- ocx start
- Wait ~18–23 seconds
Observed behavior (2.10.2)
- Proxy prints "🚀 opencodex proxy running on http://localhost:10100" and serves briefly.
- Then child exits with -1073740791 = 0xC0000409 = STATUS_STACK_BUFFER_OVERRUN (Windows GS security check).
- Service wrapper auto-restarts every 5s → permanent crash loop.
- ocx health → Proxy not healthy.
Regression confirmation
- On 2.9.1 (same machine, same config, same Bun 1.3.14): ocx start stays healthy across 25s of continuous ocx health polling (PID stable, healthz ok).
- Fault is in 2.10.x proxy code, not OS / Bun / config.
Config-independence
- Crashes with default config, with proxy field empty, and with config.json deleted.
Runtime sanity
- bun -e "console.log(Bun.version)" → 1.3.14
- ocx --version → opencodex 2.10.2
- Only the long-running proxy child process crashes.
Log excerpt (~/.opencodex/service.log, 2.10.2)
[22:57:13] child exited with code -1073740791; restarting in 5s
[22:57:18] opencodex service wrapper start ... bun_source="bundled"
🚀 opencodex proxy running on http://localhost:10100
[22:57:36] child exited with code -1073740791; restarting in 5s (up ~18s)
[22:57:41] opencodex service wrapper start
🚀 opencodex proxy running on http://localhost:10100
[22:57:59] child exited with code -1073740791; restarting in 5s (up ~18s)
Suspected cause
A stack buffer overrun in a 2.10.x proxy code path on Windows. The deterministic ~18s lifetime suggests a periodic background task (usage polling / management-API self-check / codex reauth loop) writes past a stack buffer and trips the GS check. Since 2.9.1 is unaffected, a change between 2.9.x and 2.10.0 likely introduced it.
Temporary fix
Downgrade to 2.9.1 (npm install -g --allow-scripts=bun @bitkyc08/opencodex@2.9.1) — fully stable on the same setup.
Questions
- Can you confirm a regression between 2.9.x and 2.10.0 causing a stack buffer overrun on Windows?
- Any pointer to the changed background loop so it can be narrowed down?
- Is there an env var / flag to disable the crashing background task as a short-term mitigation?
Reproduction
Summary
After upgrading from 2.9.x → 2.10.2, the proxy child process crashes ~18s after start with exit code -1073740791 (0xC0000409 = STATUS_STACK_BUFFER_OVERRUN). Downgrading back to 2.9.1 makes it stable again. Both versions bundle the same Bun 1.3.14, so this is a regression introduced in the 2.10.x line, not a Bun runtime issue.
Environment
- OpenCodex (crashing): 2.10.2
- OpenCodex (stable): 2.9.1
- Bundled Bun (both): 1.3.14
- Node: v24.14.1 (nvm) — OpenCodex runs on bundled Bun, not Node
- OS: Windows 11 25H2 (build 26200.8246; registry ProductName misreports "Windows 10 Home China", UBR 8246)
- Arch: x64
- Antivirus: 火绒 (Huorong) — disabled during testing, crash persists → not AV-related
Reproduction (on 2.10.2)
- npm install -g --allow-scripts=bun @bitkyc08/opencodex@2.10.2
(the --allow-scripts=bun flag is REQUIRED — without it the bundled Bun postinstall is skipped; verify bun.exe is ~90MB, not a few hundred bytes)
- ocx start
- Wait ~18–23 seconds
Observed behavior (2.10.2)
- Proxy prints "🚀 opencodex proxy running on http://localhost:10100" and serves briefly.
- Then child exits with -1073740791 = 0xC0000409 = STATUS_STACK_BUFFER_OVERRUN (Windows GS security check).
- Service wrapper auto-restarts every 5s → permanent crash loop.
- ocx health → Proxy not healthy.
Regression confirmation
- On 2.9.1 (same machine, same config, same Bun 1.3.14): ocx start stays healthy across 25s of continuous ocx health polling (PID stable, healthz ok).
- Fault is in 2.10.x proxy code, not OS / Bun / config.
Config-independence
- Crashes with default config, with proxy field empty, and with config.json deleted.
Runtime sanity
- bun -e "console.log(Bun.version)" → 1.3.14
- ocx --version → opencodex 2.10.2
- Only the long-running proxy child process crashes.
Log excerpt (~/.opencodex/service.log, 2.10.2)
[22:57:13] child exited with code -1073740791; restarting in 5s
[22:57:18] opencodex service wrapper start ... bun_source="bundled"
🚀 opencodex proxy running on http://localhost:10100
[22:57:36] child exited with code -1073740791; restarting in 5s (up ~18s)
[22:57:41] opencodex service wrapper start
🚀 opencodex proxy running on http://localhost:10100
[22:57:59] child exited with code -1073740791; restarting in 5s (up ~18s)
Suspected cause
A stack buffer overrun in a 2.10.x proxy code path on Windows. The deterministic ~18s lifetime suggests a periodic background task (usage polling / management-API self-check / codex reauth loop) writes past a stack buffer and trips the GS check. Since 2.9.1 is unaffected, a change between 2.9.x and 2.10.0 likely introduced it.
Temporary fix
Downgrade to 2.9.1 (npm install -g --allow-scripts=bun @bitkyc08/opencodex@2.9.1) — fully stable on the same setup.
Questions
- Can you confirm a regression between 2.9.x and 2.10.0 causing a stack buffer overrun on Windows?
- Any pointer to the changed background loop so it can be narrowed down?
- Is there an env var / flag to disable the crashing background task as a short-term mitigation?
Version
2.10.2
Operating system
win11 25H2
Provider and model
No response
Logs or error output
Screenshots and supporting files
No response
Redacted configuration
Checks
Client or integration
OpenCodex dashboard
Area
Proxy and routing
Summary
Summary
After upgrading from 2.9.x → 2.10.2, the proxy child process crashes ~18s after start with exit code -1073740791 (0xC0000409 = STATUS_STACK_BUFFER_OVERRUN). Downgrading back to 2.9.1 makes it stable again. Both versions bundle the same Bun 1.3.14, so this is a regression introduced in the 2.10.x line, not a Bun runtime issue.
Environment
Reproduction (on 2.10.2)
(the --allow-scripts=bun flag is REQUIRED — without it the bundled Bun postinstall is skipped; verify bun.exe is ~90MB, not a few hundred bytes)
Observed behavior (2.10.2)
Regression confirmation
Config-independence
Runtime sanity
Log excerpt (~/.opencodex/service.log, 2.10.2)
[22:57:13] child exited with code -1073740791; restarting in 5s
[22:57:18] opencodex service wrapper start ... bun_source="bundled"
🚀 opencodex proxy running on http://localhost:10100
[22:57:36] child exited with code -1073740791; restarting in 5s (up ~18s)
[22:57:41] opencodex service wrapper start
🚀 opencodex proxy running on http://localhost:10100
[22:57:59] child exited with code -1073740791; restarting in 5s (up ~18s)
Suspected cause
A stack buffer overrun in a 2.10.x proxy code path on Windows. The deterministic ~18s lifetime suggests a periodic background task (usage polling / management-API self-check / codex reauth loop) writes past a stack buffer and trips the GS check. Since 2.9.1 is unaffected, a change between 2.9.x and 2.10.0 likely introduced it.
Temporary fix
Downgrade to 2.9.1 (npm install -g --allow-scripts=bun @bitkyc08/opencodex@2.9.1) — fully stable on the same setup.
Questions
Reproduction
Summary
After upgrading from 2.9.x → 2.10.2, the proxy child process crashes ~18s after start with exit code -1073740791 (0xC0000409 = STATUS_STACK_BUFFER_OVERRUN). Downgrading back to 2.9.1 makes it stable again. Both versions bundle the same Bun 1.3.14, so this is a regression introduced in the 2.10.x line, not a Bun runtime issue.
Environment
Reproduction (on 2.10.2)
(the --allow-scripts=bun flag is REQUIRED — without it the bundled Bun postinstall is skipped; verify bun.exe is ~90MB, not a few hundred bytes)
Observed behavior (2.10.2)
Regression confirmation
Config-independence
Runtime sanity
Log excerpt (~/.opencodex/service.log, 2.10.2)
[22:57:13] child exited with code -1073740791; restarting in 5s
[22:57:18] opencodex service wrapper start ... bun_source="bundled"
🚀 opencodex proxy running on http://localhost:10100
[22:57:36] child exited with code -1073740791; restarting in 5s (up ~18s)
[22:57:41] opencodex service wrapper start
🚀 opencodex proxy running on http://localhost:10100
[22:57:59] child exited with code -1073740791; restarting in 5s (up ~18s)
Suspected cause
A stack buffer overrun in a 2.10.x proxy code path on Windows. The deterministic ~18s lifetime suggests a periodic background task (usage polling / management-API self-check / codex reauth loop) writes past a stack buffer and trips the GS check. Since 2.9.1 is unaffected, a change between 2.9.x and 2.10.0 likely introduced it.
Temporary fix
Downgrade to 2.9.1 (npm install -g --allow-scripts=bun @bitkyc08/opencodex@2.9.1) — fully stable on the same setup.
Questions
Version
2.10.2
Operating system
win11 25H2
Provider and model
No response
Logs or error output
Screenshots and supporting files
No response
Redacted configuration
Checks