[guidovizoso]

What a person saw

A dogfooding report on 1.0.2: a Bot on the Claude Agent SDK harness was asked to read a Slack thread and save a CSV to Google Drive. The chat showed "Looked for a tool", "Looked for a tool", "Fetch message thread from a conversation (Slack)", "Looked for a tool", and then the turn ended with no answer and no error.

Why

In one assistant message the model made two calls: the Slack fetch, which OpenBot runs (HeadlessToolsMiddleware, reaching the harness as an mcp__ag_ui__* client tool), and ToolSearch, Claude Code's own search, which the harness runs itself (TOOL_SEARCH in agent-claude-sdk/src/adapter.py).

1. Claude Code ran the Slack call first. The adapter's PostToolUse hook waits for OpenBot's result, and _hand_to_browser ends the harness run. ToolSearch has not run yet: Claude Code runs it after the Slack result comes back.
2. In HeadlessToolsMiddleware.run, pending was [Slack fetch, ToolSearch] and owned was [Slack fetch]. It ran the fetch, emitted its result, then hit owned.length !== pending.length and ended the run, assuming the other call was the browser's to answer.
3. Nobody answers ToolSearch, so the turn ended silently and the harness query waited until its timeout. The server log matched: 28 TOOL_CALL_START against 26 TOOL_CALL_RESULT, the two unanswered calls being the last two of that run.

server/src/learning/remote.ts (learned-skill reads for remote Bots) has the same loop and the same rule, so a skill read beside ToolSearch stalled the same way.

The rule

shared/harness-own-tools.ts names the tools a harness runs itself: ToolSearch and Read, the two Claude Code built-ins the adapter keeps for a full Bot (options.tools = [READ_TOOL, TOOL_SEARCH]). A test reads adapter.py and fails if the two lists drift apart.

After the middleware has answered its own calls, the run ends for the caller only if a call is left that is not one of those. When everything left is the harness's own, the middleware sends its results back and the harness carries on: Claude Code runs the search, streams its result and answers.

Why this rule and not "continue when no remaining call is one the caller offers" (callerOffers):

• callerOffers is not the full list of what the caller answers. Tools added after this middleware never appear in its input. render_ui, the generative UI tool the runtime adds from the browser's catalog, is one: the browser draws and answers it, but this middleware never sees it offered. Continuing past it would send the agent a call with no result that the browser is about to answer.
• For an agent that is not a harness, a call left without a result is not one the agent will run on its own. Sending it back makes most providers refuse the request ("tool_use without tool_result"), or makes the agent go on as if the call never happened. A call to a tool the Bot does not hold is already answered with a refusal (hidden tools), so it does not need this path.
• A named list matches what is actually true: only these two are run by the agent itself, in its next run. Anything else keeps today's behaviour.

A run never ends silently on such a call

If a run ends with only harness-own calls unanswered and nothing for this middleware or the caller to run, nobody will answer them. The middleware now ends that run with RUN_ENDED_EARLY ("The Bot stopped before it finished answering. Try again."), the sentence the chat already shows for a turn that ended without an answer, instead of a silent RUN_FINISHED. With the fix above this should not happen; it is the guard if it ever does. No new user-facing text.

The adapter

No change needed. On the continuation that carries the Slack result, the adapter resumes the waiting query (the only delivered call is the Slack one), Claude Code runs ToolSearch, the adapter streams its TOOL_CALL_RESULT, and the turn finishes with the model's answer. A new adapter test pins this down.

Tests

• server/tests/headless-tools.test.ts
  • "a step that also searches the harness's own tools goes back to the harness with this side's results": a fake agent whose first run emits, in one assistant message, an owned tool call plus ToolSearch, then RUN_FINISHED; its second run answers the search and replies. Asserts the owned tool ran once, a second agent run carries its result, and the turn ends with the agent's text and RUN_FINISHED. Before the fix: fails (one agent run, not two). After: passes.
  • "a step's call the caller offers still ends the run for the caller, beside a harness search": owned call + computer_navigate the caller offers + ToolSearch. Asserts one agent run, only the owned result, and RUN_FINISHED for the caller. Passes before and after.
  • "a run that ends on a harness's own call, with nothing left for anyone to answer, says so": a run ending on ToolSearch alone ends in RUN_ERROR with RUN_ENDED_EARLY. Before: fails (silent RUN_FINISHED). After: passes.
  • The existing "a computer tool the caller offers is left to the caller" test still passes.
• server/tests/learning-remote.test.ts: "a skill read beside the harness's own tool search goes back to the harness". Before: fails (one remote run). After: passes. The existing "mixed learning and surface calls" test (a surface call still ends the run) still passes.
• shared/harness-own-tools.test.ts: the shared list equals the tools the adapter keeps for a full Bot, read from adapter.py.
• agent-claude-sdk/tests/test_own_tool_beside_client_tool.py (streamed and not): a scripted Claude Code calls the app tool and ToolSearch in one message, running them in order. The first run ends for the app tool's result with no results; the continuation resumes the same query, streams the search's result and ends with the answer in the turn's snapshot. Passes on main too: it covers the adapter half the fix relies on.

Run locally: bun run format:check, bun run lint, bun run typecheck, bun run typecheck:tests, bun test ./server ./toolkit ./shared (against a throwaway Postgres), and python -m pytest agent-claude-sdk/tests (124 passed).

What was verified end to end, and what was not

Not reproduced in the full product with a real model: no Claude credential (API key or plan token) was available on the machine this was built on, and the harness needs one.

Verified instead, across the real process boundary: the real agent-claude-sdk app (FastAPI, ag-ui-claude-sdk, the OpenBot adapter) served over HTTP, with only the Claude Code process replaced by a scripted one that makes the two calls in one message, as in the report. The real HeadlessToolsMiddleware ran against it through an HttpAgent.

• With main's middleware: TOOL_CALL_START fetch, TOOL_CALL_START search, TOOL_CALL_RESULT fetch, RUN_FINISHED. No text, no error, the search never answered: the report's symptom.
• With this branch: the same, then the continuation's TOOL_CALL_RESULT for the search, the answer's TEXT_MESSAGE_*, MESSAGES_SNAPSHOT and RUN_FINISHED.