Linear channel: approving a HITL tool call permanently kills the session — channel context is appended after the approval response, so `collectToolApprovals` never sees it (dangling `tool_use` → Anthropic 400)

[Lukavyi]

Link to a minimal reproduction

Any Linear-channel agent with one approval-gated tool reproduces it deterministically (steps below) — the trigger is the channel's per-prompt context, not app code.

Steps to reproduce

1. Agent with an authored tool gated by approval: always(), an Anthropic model (direct @ai-sdk/anthropic or an Anthropic-compatible endpoint), and the built-in Linear channel (eve/channels/linear).
2. From Linear, delegate an issue so the model calls the gated tool → the elicitation "Approve tool call: / Yes / No" is posted, turn parks.
3. Reply "Yes" in the Agent Session.
4. Next model call 400s:

   AI_APICallError: messages.N: `tool_use` ids were found without `tool_result` blocks immediately after: toolu_… Each `tool_use` block must have a corresponding `tool_result` block in the next message.
   

5. Every subsequent prompt rebuilds the same corrupted history — the session is permanently dead.

Current vs. expected behavior

Root cause (traced through dist/src/harness/tool-loop.js, dist/src/harness/input-requests.js, ai@7.0.14, @ai-sdk/anthropic@4.0.7):

1. The Linear channel sends context (the <linear_context> block + previousComments) on every prompt, including the one that answers an approval (dispatchAgentSession → send({ context: [formatLinearContextBlock(t), …] })).
2. resolvePendingInput correctly resolves "Yes" and builds [...history, assistant(tool_use + tool-approval-request), tool(tool-approval-response)].
3. executeStepBody then appends S.input.context as user messages after that tool message, so the prompt no longer ends with the approval response.
4. The AI SDK's collectToolApprovals only inspects messages.at(-1). It now sees a user message → no approvals collected → the approved tool never executes and no tool_result is produced.
5. Client-side validation doesn't catch it (convertToLanguageModelPrompt excuses dangling tool_use ids that have an approval response anywhere in history), and @ai-sdk/anthropic silently continues over tool-approval-response parts — so Anthropic receives a dangling tool_use and rejects the request.

Expected: approving a gated tool call resumes the run — the tool executes and its tool_result lands adjacent to the tool_use, regardless of whether the channel attached context to the approving prompt.

Note the asymmetry: resolvePendingInput already defers the user's own text (queueDeferredStepInput) while an approval batch resolves, but context is exempt from that deferral and gets appended in the same step. Possible fixes:

• defer context the same way message is deferred when the resolved batch contains approval requests; or
• insert context user messages before the pending batch's responseMessages instead of after the tool message; or
• don't rely on the AI SDK's last-message scan: have the harness collect/execute approvals from the resolved batch explicitly.

This is channel-agnostic in principle (any channel passing context on the approval-answering prompt breaks), but the Linear channel always does, so every Linear approval is affected. Telegram/eve-TUI approvals usually work, which is probably why this survived testing.

Likely related (same invariant, different triggers): #460, #236, #203.

Workaround we're running in production — a pnpm patch on dist/src/harness/tool-loop.js that skips the context push when the resolved messages end in a tool message carrying a tool-approval-response (the dropped block is a duplicate; the same context is already in history from the turn that parked the approval):

let approvalTail=(()=>{let e=j[j.length-1];return e?.role===`tool`&&Array.isArray(e.content)&&e.content.some(e=>e?.type===`tool-approval-response`)})();
if(S.input?.context!==void 0&&!approvalTail)for(let e of S.input.context)j.push({content:e,role:`user`});

eve version

0.19.0 (also reproduced on 0.16.2; the context-push code is unchanged between them)

Environment

Node 24.x (Vercel), pnpm 9.15.0, ai@7.0.14, @ai-sdk/anthropic@4.0.7

Where does the bug occur?

Production (eve start / deployed on Vercel)

Deployment

Vercel, Linear channel via eve/channels/linear with default events

Build and runtime logs

[eve:harness.tool-loop] tool-loop stream error {
  error: {
    message: 'AI_APICallError: messages.4: `tool_use` ids were found without `tool_result` blocks immediately after: toolu_01LUgzdHzc49TgFQSaGGunTe. …',
    name: 'AI_APICallError',
    detail: 'APICallError … at _AnthropicLanguageModel.doStream … at async run (file:///var/task/_libs/eve.mjs:40164:11)'
  }
}
[eve:harness.tool-loop] model call failed terminally { sessionId: 'wrun_01KWM9VACG43PCYFVJKXNBG0T9', turnId: 'turn_1', … }

Additional context

The failure is unrecoverable by design of the resume path: the pending batch is cleared on the first resolved-but-400 attempt, and the corrupted history is durable, so the user sees "This session could not recover from an error … Start a new Linear agent session".

[rpelevin]

I would pin this as a channel-context / approval-resume ordering invariant.

Once a pending approval is answered, the resolved approval batch should be consumed before any channel context is appended after it. The safe sequence is:

• resolve the pending input against the original tool call id
• if approved, execute the tool exactly once and append its tool_result immediately after the matching tool_use
• if denied, append one terminal no-effect result for that tool call id
• defer Linear context / previous comments to the next normal user input, or place them before the resolved approval batch
• fail closed if the approval response cannot be tied to the pending input id and tool call id

The important boundary is that channel context is not executable authority. It can inform the next turn, but it should not move the approval response away from the tool_use that it authorizes.

Regression cases I would add:

• approving from Linear with context attached still produces an adjacent tool_result
• denial produces no tool execution and one terminal no-effect result
• context appended after approval is deferred and does not affect collectToolApprovals
• stale approval for a different pending input id fails closed
• duplicate approval responses execute at most once
• provider prompt validation catches a dangling tool_use before the API call

That keeps the approval transport separate from the authority to execute, and prevents a harmless channel context block from voiding the approved call.

Boundary: architecture and conformance feedback only; no claim about Vercel/Eve alignment, implementation correctness, acceptance, partnership, integration, customer interest, official alignment, Eve usage, or Neura usage.

[iroiro147]

I can take a focused pass on this. I’ll keep the first PR scoped to the approval-resume ordering issue: when resolving a pending tool approval, channel context should not be appended after the tool approval response in a way that hides it from approval collection. I’ll add regression coverage for the context-bearing approval path and keep the broader transcript-obligation/recovery work separate unless the focused fix naturally needs it.

[rpelevin]

That sounds like exactly the right first cut. Thanks for taking a focused pass on it.

The part I'd be happiest to see locked down is the context-bearing approval path: once the pending approval is resolved, the approval result stays adjacent to the original tool_use, and any Linear/comment context is treated as context for the next turn rather than executable authority for the current one.

Even a tiny regression matrix around approve, deny, and stale-or-duplicate approval would make this much easier to reason about. Appreciate you keeping the transcript/recovery work separate unless the narrow fix really needs it.

[iroiro147]

Thanks, this guidance helped shape the focused fix. I opened #599 with the scope kept to the approval-resume ordering path: approval-with-attached-context is deferred so the approval result stays at the tail of the resume call, and the follow-up context is handled in the next internal step rather than as executable authority for the current approval. The regression coverage in that PR covers the context-bearing approval resume path, denial/no-execution behavior, and stale pending-response handling while leaving the broader transcript/recovery work out of scope.