Codex App aborts turn with invalid_id_prefix after custom Stop hook feedback

Open 💬 1 comment Opened Jul 15, 2026 by dalki-bot
Clarification: The dependency-cache false positive that triggered this incident came from a third-party oh-my-codex Stop hook, not from Codex itself. This issue is specifically about Codex App aborting the turn with an invalid message ID while handling custom hook feedback.

Summary

Codex App failed to process feedback from a custom Stop hook safely. After the hook returned a blocking result and Codex displayed the feedback as a <hook_prompt>, the next request failed with:

[ApiIdParam] [input[0].id] [invalid_id_prefix]
Invalid 'input[0].id': '019f66db-dcf9-7a63-915e-e3ae2a47690b'.
Expected an ID that begins with 'msg'.

The active turn was interrupted.

The content that caused the hook to block was a false positive in the third-party hook and will be addressed in that project's repository. Codex should nevertheless validate or isolate hook feedback so that a custom hook cannot cause a malformed API input item.

Environment

  • Surface: Codex App
  • Runtime: native hook, outside tmux
  • OS: macOS
  • Hook type: custom Stop command configured through ~/.codex/hooks.json
  • Third-party hook provider in the observed incident: oh-my-codex 0.20.1

Observed flow

  1. A custom Stop hook returned a blocking result containing a reason/system message.
  2. Codex rendered the returned feedback as a hook prompt.
  3. Codex attempted to continue with an input item whose ID was a UUID-like value:

``text
019f66db-dcf9-7a63-915e-e3ae2a47690b
``

  1. The API rejected it because message IDs must begin with msg.
  2. The turn was aborted.

Actual behavior

A custom hook result caused the subsequent API request to contain an invalid input[0].id, terminating the active turn.

Expected behavior

Codex should safely handle custom hook feedback even if the hook blocks a turn or returns unexpected content.

At minimum:

  • generated hook-feedback input items should receive valid msg... identifiers;
  • all generated input items should be validated before sending the API request;
  • malformed optional hook feedback should be surfaced separately;
  • failure to serialize hook feedback should not abort or corrupt the active user turn.

Scope clarification

Not a Codex bug in this report

The hook's original dependency-cache audit false positive belongs to the third-party oh-my-codex implementation.

Codex behavior reported here

The invalid_id_prefix failure and active-turn interruption occurred while Codex App processed the custom hook feedback.

Reproduction direction

  1. Configure a custom Stop hook that returns a blocking result with a reason/system message.
  2. Trigger the Stop hook.
  3. Allow Codex App to inject or render the resulting hook feedback.
  4. Continue the turn.
  5. Observe whether the generated API input uses a UUID-like hook/run item ID instead of a valid msg... ID.

The issue may depend on the native-hook Codex App path rather than the CLI path.

Acceptance criteria

  • Stop hook feedback is converted into a valid API message item.
  • Hook run IDs are not reused as API message IDs.
  • Every outgoing input item is schema-validated before the request.
  • A malformed custom hook result cannot abort the active turn.
  • Regression coverage includes a blocking custom Stop hook followed by another user/model turn.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗