codex - 💡(How to fix) Fix Blocking stop hook continuation can fail with invalid local message id [1 participants]

Bug

A blocking stop hook can break the Codex turn instead of prompting Codex to fix the blocked condition.

Observed failure:

{
  "error": {
    "message": "Invalid 'input[118].id': 'c047686e-8eaf-4c21-9eba-e25d3122d898'. Expected an ID that begins with 'msg'.",
    "type": "invalid_request_error",
    "param": "input[118].id",
    "code": "invalid_value"
  }
}

Why this matters

A stop hook with decision: "block" is supposed to inject a continuation prompt, for example telling Codex to fix failing lint/type/test checks before stopping.

In this failure mode, the stop hook successfully blocks and emits the continuation prompt, but the next Responses API request rejects the conversation input. That makes the hook mechanism counterproductive: it prevents Codex from continuing to fix the problem.

Expected behavior

When a stop hook blocks, Codex should append the hook continuation prompt and continue the turn normally.

Actual behavior

Codex sends a locally generated UUID as input[].id for a message item. The Responses API rejects it because message ids must be server-generated msg... ids.

Root-cause hypothesis

build_hook_prompt_message creates a user message with a local UUID. Later, attach_item_ids reattaches hidden item ids into the serialized Responses API request body.

That path appears to treat local message UUIDs the same as server-generated message ids, so a local UUID is sent as a wire message.id.

Reference fix

I prepared a minimal fix in a fork.

Reference commit: https://github.com/shawnsw/codex/commit/15286e639ad4f11771ddf1393b565f503c0aafc7

Approach:

• only reattach message.id when it looks like a server-generated msg... id
• continue preserving ids for other Responses API output item types
• add regression coverage for local UUIDs and server message ids