Felix Arntz

feat(harness-acp): introduce ACP harness adapter as a meta adapter to connect to any ACP compatible harness (#18483) ## Background AI SDK harness integrations currently require a dedicated adapter for each coding-agent runtime. ACP provides a common protocol that can support multiple runtimes through one adapter while keeping runtime-specific installation and authentication details in small profiles. Some harnesses only offer an ACP adapter as the sole way for programmatic control over their harness, so for those harnesses having an ACP adapter unblocks supporting them by our harness layer. ## Summary This adds `harness-acp`, a meta adapter for ACP v1 implementations. The adapter owns the generic sandbox bridge, protocol translation, host-tool relay, approvals, and lifecycle behavior, while callers configure the underlying ACP runtime declaratively. - Support simple and lockfile-pinned NPM acquisition for arbitrary ACP implementations. - Support direct and AI Gateway authentication with runtime-resolved environment variables and adapter-specific Gateway routes. - Translate ACP streams, native tools, host tools, approvals, skills, session modes, and resumable lifecycle state into Harness APIs. - Add complete Claude Code, Codex, and Grok Build profiles across documentation and interactive examples. ## End-to-End Verification - Exercised the added Claude Code ACP, Codex ACP, and Grok Build ACP through the interactive Harness example. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) ## Related Issues See #16956.

feat(harness): allow changing harness settings between turns via `prepareCall()` support on `HarnessAgent` (#19828) ## Background `HarnessAgent` settings were fixed when an agent was created, preventing callers from adapting instructions, skills, and tools between completed turns. `ToolLoopAgent` already supported `prepareCall()` and `callOptionsSchema`, allowing to dynamically modify certain settings in between turns. ## Summary This aligns `HarnessAgent` with the `ToolLoopAgent` call-options pattern while keeping settings fixed throughout an active turn and its continuations. - Add `callOptionsSchema` and `prepareCall` support for deriving per-turn instructions, skills, and tools. - Capture active turn settings in continuation state so suspended and resumed turns cannot pick up later configuration. - Update harness adapters to apply settings changes between turns, including ACP skill refreshes and instruction guidance. - Make `writeSkills` safely replace only harness-owned skills and skip unchanged content using a manifest with SHA-256 hashes. - Add documentation, unit coverage, and changing-settings examples for every harness. ## End-to-End Verification Ran the new `changing-settings` examples against all harnesses. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review)

feat(harness): support `askUserQuestions` tool including support for normalization across harness adapters (#20267) ## Background Harness question tools expose incompatible inputs and previously had no reliable client-side answer channel. This made structured question flows unusable through `HarnessAgent`. ## Summary - Add the normalized `askUserQuestions` tool contract, including multi-question, partial-answer, free-form, cancellation, and provider metadata support. - Translate native question calls and answers for all supported harness adapters (see below). - Preserve pending question state across suspension and cross-process continuation. - Add an interactive question renderer to the Next.js harness example. - Omit question tools from ACP adapters where the runtime cannot provide an answerable client request. Harness support: - Claude Code: Supported. - Cline: Supported. - Codex: Unsupported — SDK has no question tool. - Cursor: Unsupported — question tool is not exposed in ACP mode. - Deep Agents: Unsupported — SDK has no question tool. - fx: Unsupported — question interaction is disabled in ACP mode. - Grok Build: Supported. - OpenCode: Supported. - Pi: Unsupported — SDK has no question tool. - Example ACP harness adapters: - Claude Code ACP: Supported. - Codex ACP: Supported. ## End-to-End Verification Verified the shared question example against Claude Code, Cline, OpenCode, Grok Build, Codex ACP, and Claude Code ACP. Also verified the interactive flow in `examples/harness-e2e-next`. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) ## Future Work - Add support for additional ACP runtimes when they expose an answerable native question request. - Address plan mode from the original issue separately, tracked in #19944. ## Related Issues Fixes #19755

feat(harness): support request transformations in network sandbox abstraction and use it to apply credential brokering when available (#18859) ## Background Bridge-based harnesses currently forward provider credentials into sandboxed agent processes, which is far from ideal from a security perspective. Credential brokering allows us to keep those credentials only in the host environment and inject them into the relevant outgoing requests from the sandbox at the host boundary. ## Summary - Add optional `setRequestTransformations()` and `addRequestTransformations()` to the network sandbox abstraction. - Update the Vercel Sandbox implementation to support it, via its `networkPolicy` layer. - Preserve authoritative allow/deny policy and `forwardURL` rules while transformations are added, replaced, deferred, or restored across session resume. - Broker direct-provider and AI Gateway credentials for all bridge based harnesses: Claude Code, Codex, Deep Agents, Grok Build, OpenCode, and ACP-based harnesses. - Warn and retain legacy credential forwarding when a sandbox implementation does not expose additive request transformations. - Add shared credential-brokering utilities, structural conventions, tests, documentation, and an end-to-end Vercel Sandbox example. - For Codex specifically, disable websockets mode conditionally to be able to apply credential brokering. ## End-to-End Verification Ran many static and interactive examples across all bridge harnesses to verify continued correct execution with the new path of brokered credentials applied. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review)

feat(harness-opencode): implement harness adapter for OpenCode (#16255) ## Summary After #15969 added the initial harness adapters, this PR implements the harness adapter for OpenCode. - Similar to Claude Code and Codex, it runs inside the sandbox via bridge communication. - Examples and docs added. - Since this will be the first package release, the changeset is `major` instead of `patch`. - Simplified some docs that were listing harness adapters, to not have to maintain those lists in too many places. ## Manual Verification New non-interactive and interactive examples similar to the ones for the other harnesses were added that can be used to verify behavior. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) --------- Co-authored-by: Gregor Martynus <39992+gr2m@users.noreply.github.com>

feat(harness): add support for structured output to `HarnessAgent` via `output` property (#18937) ## Background `HarnessAgent` previously pinned its output type to `never`, preventing callers from using the typed structured-output workflow supported by `ToolLoopAgent` and several underlying harness runtimes. ## Summary - Add constructor-level `output` support with typed final, partial, and element output streams. - Add an independent JSON Schema response-format contract to HarnessV1 without coupling `harness` to `provider`. - Map structured output to Claude Code, Cline, Codex, Deep Agents, Grok Build, and OpenCode; unsupported adapters and runtime configurations throw `HarnessCapabilityUnsupportedError`. - Let ACP profiles explicitly map output schemas into implementation-specific prompt metadata. - Add adapter documentation, tests, and runnable structured-output examples for every harness. ## Contributor Credit Thanks to @niranjan94 for reporting the missing structured-output path and documenting the underlying runtime capabilities. ## End-to-End Verification Ran `./tools/run-harness-agent-examples.sh --example with-structured-output` across all harnesses. Supported adapters generated and parsed the requested recipe schema; Pi and Codex ACP surfaced their expected unsupported-capability errors. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) ## Related Issues Fixes #16120 Co-authored-by: Niranjan Rajendran <2404372+niranjan94@users.noreply.github.com>

feat(harness): add experimental support for steering agent conversations mid-turn (#19059) ## Background `HarnessAgent` did not expose steering the agent mid-turn, a common feature that many harnesses support. A few related primitives like lower-level API surfaces to submit another prompt mid-turn were already in place, but weren't properly wired up and didn't actually work end-to-end. ## Summary This adds an experimental steering API with acknowledged delivery to the active turn's next safe input boundary. - Add `experimental_steer` and `experimental_steerTurn` with active-turn and capability checks. - Add ID-based bridge acknowledgements and reconnect-safe resubmission. - Wire steering through supported harness adapters while preserving explicit unsupported-capability errors. - Add matching weather-tool steering examples and regression coverage across harnesses. ### Known limitations - Steering requires to operate on the same `HarnessAgentSession` instance that is actually controlling the current agent turn. Therefore, cross-process steering (e.g. in a separate REST request than where that turn was started) is currently not properly supported. The only workaround is relying on environments where the same session instance can be accessed in the other context too, e.g. a single-process dev server where you can store those session objects in memory and then retrieve them in the other request. - The mid-turn user prompts cannot properly be represented in the AI SDK messages list, because they're injected mid-turn into what AI SDK expects to be a stream of exclusively agent-owned stream parts. Fixing this will require a higher-level concept of steering support in AI SDK Core. ## End-to-End Verification Ran the new `steer.ts` examples in `examples/ai-functions/src/harness-agent`. ## Checklist - [x] All commits are signed with `git commit -s`. - [x] Tests have been added or updated and pass. - [ ] Documentation has been added or updated. - [x] A patch changeset has been added. - [x] The changes have been reviewed and tested. ## Related Issues Fixes #18274 See #19125 for making this a more proper implementation in the future

feat(harness): add support for per-harness MCP servers (#18647) ## Background Harness adapters could not consistently accept user-configured MCP servers, and external MCP tool calls could be rejected as unknown tools or lose their dynamic classification. At the same time, typed `HarnessAgent` tools must remain static even when a runtime transports them through MCP. ## Summary With this PR, all harness adapters can receive MCP servers and process tool calls to these MCP servers. - Add an optional `mcpServers: Record<string, unknown>` setting across harness adapters and forward it in each runtime's native format. - Merge external servers with any adapter-owned MCP server used for host tools, without deeply validating runtime-specific configuration. - Mark only external MCP tool calls as dynamic while preserving typed built-in and `HarnessAgent` tools. - Add ACP runtime-specific classification through `isMcpToolCall`, plus regression coverage, Context7 examples, documentation, and a konsistent invariant. ## End-to-End Verification - Ran the added Context7 MCP examples against all harnesses. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review)

feat(harness-cline): implement Cline harness adapter (#18821) ## Background This is built on top of #18102, continuing the effort of implementing a full Cline harness adapter. That PR was lacking signed commits, plus after the feedback we agreed on that I will address it myself. ## Summary See description of #18102, which is reflected in the first commit https://github.com/vercel/ai/commit/7d6dc4c6d6927f3e6d3e6f1b432956b655ae23a3 in this PR. All subsequent commits are additional pieces that were missing or not fully working yet per our latest harness feature requirements. ## Contributor Credit Credit for the bulk of this work goes to @saoudrizwan and the rest of the Cline team involved in the original PR. ## End-to-End Verification Ran all Cline harness examples added, including spot checks using the interactive ones. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [ ] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review) Co-authored-by: Saoud Rizwan <7799382+saoudrizwan@users.noreply.github.com>

feat(harness): add tool filtering via `activeTools` and `inactiveTools` (#16527) ## Background `HarnessAgent` could not limit the tool set exposed to harness runtimes the way `ToolLoopAgent` can. While for custom tools one could partially work around it by not even providing tools, for built-in tools it doesn't work. the only restriction mechanism is the general `permissionMode`, but that's less granular. ## Summary This PR adds `activeTools` and `inactiveTools` to `HarnessAgent` as mutually exclusive allowlist/denylist controls. Host-executed tools are filtered before adapter handoff; built-in tools are filtered through native adapter support where available, or through hidden auto-denial on approval-capable adapters. - Adds typed `activeTools` / `inactiveTools` settings across harness built-ins and user tools. - Filters inactive host tools before adapters see them and denies unexpected inactive calls. - Adds built-in filtering support across Claude Code, Deep Agents, OpenCode, and Pi, while Codex explicitly rejects built-in filtering. - Adds AI functions examples and harness docs for tool filtering. - Declares Claude Code `Monitor` as a built-in tool. ## Manual Verification Run the newly added function examples and the interactive examples. Note that Codex doesn't support built-in tool filtering, that's a known limitation of the underlying SDK. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [x] Documentation has been added / updated (for bug fixes / features) - [x] A _patch_ changeset for relevant packages has been added (for bug fixes / features - run `pnpm changeset` in the project root) - [x] I have reviewed this pull request (self-review)