[ya-luotao]

Syncs the gem with Python SDK 0.2.174 (previously 0.2.162). Since 0.2.162 only five Python PRs touch src/. The other releases are bundled-CLI bumps and CI changes.

Python PR	Verdict	Here
#1422 parallel tool calls in get_session_messages	adapted	below
#1336 include_hook_events docs	ported	docs/options.md
#1331 hook outputs / input fields	already in 1.2.0	—
#1332 SystemInitData	already in 1.2.0	InitMessage#capabilities etc.
#1380 ignoreViolations type	already matched	Hash[String, Array[String]] since before 1.0

#1422: the tool calls a parallel batch's walk passed by

#157 (1.2.0) put back the off-chain results of parallel tool calls. It only looked for results of calls already on the chain. The conversation goes on from the result written last. When that result answers an earlier call than the batch's last, the tool_use entries written after it are off the parentUuid path, so both readers dropped those calls and their results. Python's four result orders give this on main:

[0, 1, 2]  -> prompt call-0 call-1 call-2 result-0 result-1 result-2 answer
[2, 1, 0]  -> prompt call-0 result-0 answer
[1, 2, 0]  -> prompt call-0 result-0 answer
[0, 2, 1]  -> prompt call-0 call-1 result-0 result-1 answer

Now every entry of an API message on the chain goes back right after that message's last entry on the chain, in timestamp order with file order on a tie, as in Python and TS. Then the results are re-attached as before. A result the CLI parented on a hook attachment is matched to its call by tool_use_id when the same agent wrote both. A tool_use_id claimed by two API messages is never used.

Ruby-specific, on purpose:

• Fix session reads, listing and mutations (parallel tool results, worktrees, encodings, long and odd paths) #157's guards stay: the chain's own result wins, at most one result per call, and a result that heads a branch a rewind dropped stays out. Python has none of these.
• Both the main and the subagent readers are fixed. Python #1422 leaves get_subagent_messages on the single-branch walk.
• The dropped-branch guard was too wide on real data, so it is narrowed (third commit). Going on from a result no longer counts as a dropped branch when what goes on is a later call of the same batch, another result of the batch (the CLI sometimes parents one under an earlier result's hook attachment), or a meta entry (the [Image: ...] note under a screenshot result). A branch that goes on through a meta entry is still caught (spec), and so is one that goes on through another result of the batch (fourth commit, from the Codex review: result_a → attachment → result_b → reply on a dropped branch had put result_a back; a batch result now counts as going on once something goes on from it). The fourth commit changes nothing on the 7479 local transcripts (per-file diff against the third).
• Recovering whole API messages means that a rewind landing inside a parallel batch now shows the batch's later calls too. That is what TS and Python do, and the response is on the chain, so its blocks belong to it.

Verification

• bundle exec rake: 4371 examples, 0 failures; rubocop clean. 16 new examples in spec/unit/session_parallel_tool_results_spec.rb: Python's four orders, store-backed with a retried mirror batch, a batch that ends the transcript, paging, timestamp order, the streamed shape, a result under an attachment, a result under another result (and the same on a dropped branch), the meta note, rewind through a meta entry, an earlier attempt at the turn, and a subagent transcript. 13 fail against main (the abc order, rewind-through-a-meta-entry and the dropped branch with one result under another already passed there; the last two pin that the narrowed guard still holds).
• Ran both readers (old and new) over 7474 local CLI transcripts, 1.24M messages:

	before	after
tool_use entries of a returned API message missing from the output	4610	0
tool calls returned without a result	319	43
results returned without their call	17	1
duplicate uuid / tool_use / tool_result	0	0

The 43 are 32 calls still running when the session ended (no result in the file) and 11 whose result heads an off-chain branch with an assistant reply (a real dropped branch). The 1 is a transcript whose first entry is a result whose call is not in the file.

• No wire-protocol change, so the integration suite is not affected. No public API change, so sig/ is unchanged.

Affected sessions return more messages than before, so offset:/limit: pages over them shift (CHANGELOG).

🤖 Generated with Claude Code

https://claude.ai/code/session_01PQPc2HryX1S85K3x1FqRfT

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-28T10:44:07.664883Z	992e1bf	PR opened
🔒 Security Review	✅ Completed 2026-10-28T10:45:23.182041Z	992e1bf	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 992e1bf96a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve dropped-branch detection across consecutive tool results

When an abandoned branch contains result_a -> hook attachment -> result_b -> assistant reply, and a rewind continues from the batch's tool calls with a new prompt, excluding every batch result from continued_from hides the continuation from result_a to result_b. Only result_b is marked as continued, so result_a is incorrectly reattached to the current conversation even though its branch was dropped. I reproduced this with the transcript fixture: the parent revision excludes both abandoned results, while this revision returns the old result for call A. Preserve continuation detection through excluded batch results when their branch ultimately leads to an abandoned reply.

Useful? React with 👍 / 👎.