Best possible solution:

Land #102276 as the canonical proof-positive fix for #102252, then close this duplicate branch.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level. Current main defers prepared parallel tool calls and lacks a pre-execute abort guard, while the linked issue and both candidate tests exercise aborting during beforeToolCall.

Is this the best way to solve the issue?

No, this PR is not the best landing path. The runtime fix shape is right, but #102276 carries the same fix with stronger real behavior proof and stronger regression assertions.

Security review:

Security review cleared: The diff only changes internal agent-core cancellation logic and colocated tests; it adds no dependency, workflow, secret, install, publishing, or supply-chain surface.

AGENTS.md: found and applied where relevant.

What I checked:

• Current main defers prepared parallel calls: On current main, executeToolCallsParallel stores prepared calls as deferred thunks and later starts them through Promise.all, which is the gap described by the linked issue. (packages/agent-core/src/agent-loop.ts:745, 0307deacfac7)
• Current main lacks the pre-execute guard: executePreparedToolCall still calls prepared.tool.execute without first checking signal?.aborted, and finalizeExecutedToolCall always reports prepared executions as started. (packages/agent-core/src/agent-loop.ts:984, 0307deacfac7)
• Default caller path is affected: Agent defaults toolExecution to parallel, so the deferred prepared-call path is the normal path unless a caller opts into sequential execution. (packages/agent-core/src/agent.ts:266, 0307deacfac7)
• This PR applies the same runtime fix shape: The PR head adds executionStarted, returns an aborted result before execute when the signal is already aborted, and suppresses afterToolCall for work that never started. (packages/agent-core/src/agent-loop.ts:989, 8dab3306be1c)
• This PR test covers the core race but not the stronger hook assertion: The added test asserts the prepared paid-style tool and aborting tool do not execute and both end events report executionStarted: false. (packages/agent-core/src/agent-loop.test.ts:1186, 8dab3306be1c)
• Canonical sibling has stronger regression coverage: The sibling PR's test explicitly forces parallel execution, verifies neither tool executes, verifies afterToolCall is not called, and checks both aborted tool results. (packages/agent-core/src/agent-loop.test.ts:1186, 231812d76644)

Likely related people:

• vincentkoc: Current blame attributes the packaged agent-loop.ts, agent-loop.test.ts, and agent.ts surfaces, including the prepared parallel execution path, to recent agent-core extraction work. (role: recent area contributor; confidence: high; commits: 5a5b4c5b105f, e085fa1a3ffd; files: packages/agent-core/src/agent-loop.ts, packages/agent-core/src/agent-loop.test.ts, packages/agent-core/src/agent.ts)
• steipete: History on the predecessor steering loop shows earlier agent loop queue and typing work before the packaged agent-core extraction. (role: earlier agent-loop contributor; confidence: medium; commits: 44339a644761, 0f271ab535c9, b635e8365135; files: src/agents/steerable-agent-loop.ts)
• szsip239: Authored the merged adjacent abort-loop PR that changed the same loop and test surface for a distinct post-tool abort continuation bug. (role: adjacent abort behavior contributor; confidence: medium; commits: 7fe287b0d30d; files: packages/agent-core/src/agent-loop.ts, packages/agent-core/src/agent-loop.test.ts)

Codex review notes: model internal, reasoning high; reviewed against 0307deacfac7.