Summary

On Linux, the npm-installed codex wrapper appears to abort during shutdown in Node/libuv teardown when used as the codex app-server entrypoint for a long-running service.

This does not currently look like an adapter-specific bug in the caller. In local testing, the problem reproduces when launching Codex through the npm codex wrapper, while the same service becomes stable when CODEX_CLI_BIN is pointed directly at the bundled native Codex binary.

Environment

• OS: Debian 13 (trixie)
• Kernel: Linux 6.12.43
• Node: v20.19.4
• Codex CLI: 0.128.0
• Install shape: npm global install of @openai/codex

Observed behavior

A long-running service starts Codex using the normal codex app-server --listen stdio:// ... flow.

When the service is restarted repeatedly, the wrapper-mode process frequently leaves a new core dump. The core is reported as the Node wrapper process, for example:

• node .../bin/codex -c model="gpt-5.4" -c model_reasoning_effort="high" ...

GDB backtrace

A representative core shows:

Program terminated with signal SIGABRT, Aborted.
frame 0: abort()
frame 1: uv__epoll_ctl_prep(...)
frame 2: uv__io_poll(...)
frame 3: node::tracing::Agent::~Agent()
frame 4: node::TearDownOncePerProcess()
frame 5: node::Start(int, char**)

So this appears to be a wrapper/Node/libuv teardown abort, not an ordinary application-level failure inside the caller.

Reproduction comparison

I ran a controlled restart comparison against the same long-running service process.

A. Wrapper mode

The service used the default npm-installed codex wrapper.

Repeated restart result:

• restart 1: new core dump
• restart 2: new core dump
• restart 3: new core dump

B. Native binary mode

The service was reconfigured to point directly at the bundled native binary instead of the npm wrapper.

Repeated restart result after native mode was active:

• restart 1 after switching: one final core from the old wrapper process during the transition
• restart 2: no new core dump
• restart 3: no new core dump

This strongly suggests the instability is tied to the Node wrapper shutdown path rather than to the underlying app-server workflow itself.

Why this seems worth reporting

The current npm wrapper is the default and most discoverable entrypoint. If it can leave repeatable SIGABRT core dumps during normal service restarts, downstream integrators may see frequent crash artifacts even when the bundled native Codex binary is otherwise stable.

Expected behavior

Using the default npm-installed codex wrapper as the app-server entrypoint for a long-running service should not abort during normal restart/shutdown cycles.

Possible directions

Any of these would help:

• fix the wrapper/Node teardown abort itself
• document known Linux wrapper instability if this is already understood
• provide a stable first-class way to resolve or opt into the bundled native binary without relying on internal npm package layout