alpha codex-cli 0.116.0-alpha.11 can exit after external request is rejected before any bot-side turn starts

Summary

When using codex-cli 0.116.0-alpha.11 as the local CLI binary inside a shell wrapper, the Codex process can be terminated unexpectedly after an external Telegram-side request is rejected by an ownership gate.

The important part is that the Telegram bot does not start a Codex turn in this path. It rejects the Telegram message early and returns. Even so, the local alpha Codex CLI process exits with code 137.

The same flow does not reproduce when switching the local CLI binary back to the stable Homebrew codex.

Environment

• Codex alpha binary: codex-cli 0.116.0-alpha.11
• Stable binary used for comparison: Homebrew codex
• Host OS: macOS
• Local CLI launched from a shell wrapper function (hcodex) in a normal terminal session
• The wrapper enables:
• -c features.codex_hooks=true
• -c notify=[...]

What makes this suspicious

This is not the official expected Codex usage path; it is part of an external integration. But the failure mode is still notable because:

1. the Telegram-side request is rejected before any bot-driven Codex turn starts
2. the local shell stays alive
3. only the alpha Codex process exits
4. the stable Homebrew Codex does not reproduce the problem under the same flow

Reproduction shape

This is the conceptual repro:

1. Launch local Codex CLI with the alpha binary through a shell wrapper.
2. Let the local CLI session become the "owner" of a workspace.
3. From Telegram, send a normal text message into a thread that is intentionally blocked by an ownership gate.
4. The Telegram bot replies with a rejection message such as:

Local Codex CLI currently owns this session. Run /attach_cli_session to take it over in Telegram.

1. Shortly after that rejection, the local alpha Codex process exits unexpectedly.

This reproduces both when the local CLI already started a session and when it is just open in the terminal.

Expected behavior

If the external system rejects the Telegram message and does not forward it into Codex, the local Codex CLI process should remain unaffected.

Actual behavior

The local alpha Codex process exits with code 137.

Observations from instrumentation

From the integration logs:

• the Telegram-side path only logs a rejection event and returns early
• there is no bot-side Codex turn start for the rejected message
• there is no explicit local CLI handoff / attach action
• the local shell remains alive
• the exiting child process is the alpha Codex binary itself

Example diagnostic shape from the integration:

• telegram.cli_owned.rejected
• then local CLI:
• shell_process_exited
• exit_code = 137
• diagnostic payload captured the child process as:
• child_command = /Volumes/Data/Github/codex/.threadbridge/bin/codex -c features.codex_hooks=true -c notify=[...]

In one sample where the local CLI had already completed a turn, the timeline looked like:

1. local CLI session starts normally
2. local prompt submit / stop / turn complete all succeed
3. Telegram sends a message that is rejected by the ownership gate
4. a short time later, the alpha Codex process exits with 137

Comparison with stable Codex

Switching the wrapper back to the stable Homebrew codex binary avoids the problem. The same Telegram rejection flow does not terminate the local stable Codex CLI process.

Open question

I do not yet know the exact internal trigger. But the current evidence suggests:

• the Telegram-side rejected message is not being forwarded into a bot-driven Codex turn
• the alpha Codex binary is still being terminated afterward
• the problem appears specific to the alpha binary behavior under this integration pattern

If useful, I can provide the exact wrapper snippet and more detailed event timelines.