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-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 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)

feat(harness): add sandbox specific expansion for harness abstraction, add `sandbox-just-bash` and `sandbox-vercel` (#15919) ## Background This is the first PR broken out from #15496, the harness abstraction layer. **All code in these new packages is considered experimental.** ## Summary - Implement the harness specific expansion of the sandbox abstraction, called `HarnessV1NetworkSandboxSession`. Its shape is driven by harness needs (see original draft PR). - The type has a `restricted()` method which returns an (effectively lower-capability) instance of `Experimental_SandboxSession`. This instance should be passed to tool calls, _not_ the network session instance. Otherwise tools would be able to perform actions that go widely beyond their authority, e.g. stopping the sandbox. - Eventually, this could live in `provider-utils` or `specification` as an expansion to the existing `Experimental_SandboxSession`, however we leave it in this experimental package, particularly because it's directly related to the harness abstraction. - Implement `HarnessV1SandboxProvider`, a basically stateless container for sandbox definition. It allows to define a specific sandbox definition in the file root, similarly to e.g. `ToolLoopAgent` (or the future `HarnessAgent`). The `createSession()` and `resumeSession()` methods are then used to create _stateful_ sandboxes by actually bootstrapping the resource. - Implement adapters for `just-bash` and Vercel Sandbox. These provide both an implementation of `Experimental_SandboxSession` and `HarnessV1NetworkSandboxSession`, accessible via the `HarnessV1SandboxProvider`. **Note:** Merging this PR will publish the first canary releases of the new packages: - `@ai-sdk/harness` - `@ai-sdk/sandbox-just-bash` - `@ai-sdk/sandbox-vercel` ## Manual Verification - Verification has been happening via the original PR #15496. - The examples in `examples/ai-functions` were updated to use these implementations instead of local 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) - [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)

fix(harness): properly support client-side / host-side tools and handle unfinished turn semantics (#17541) ## Background `HarnessAgent` treated tools without `execute` as completed with an undefined result, so client-side tool calls could not pause and resume the underlying harness turn. Turn completion and step accounting could also become inconsistent around these pauses. ## Summary - Pause unfinished turns while client-side / host-side tool results are pending, including across session suspension and resume. - Continue turns from direct result continuations or trailing tool messages, and expose `session.hasUnfinishedTurn()` for lifecycle decisions. - Build step results from explicit `finish-step` events while filtering replayed continuation events. - Add unit coverage, documentation, and interactive examples for Claude Code, Codex, Deep Agents, OpenCode, and Pi. ## End-to-End Verification Run the new client-side tool examples in `examples/ai-functions/src/harness-agent`, and the `basic` interactive examples in `examples/harness-e2e-next` (ask "who am I?" to trigger the client-side tool call). ## 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)

chore(harness): refactor bridge code to break out stream event emission from launcher to make it testable (#17808) ## Background Harness bridge entrypoints currently combine process orchestration with substantial stream event translation logic, which prevents that logic from being imported and tested in isolation because test files by definition cannot import from that `index.ts` file due to its side effects. ## Summary - Extract stream event translation for Claude Code, Codex, Deep Agents, and OpenCode into dedicated `createEmitStreamEvent` factories. - Preserve existing event ordering, control flow, permission handling, and runtime behavior while keeping launcher concerns in each bridge entrypoint. - Add focused unit coverage for content, tool, usage, model, retry, error, and compaction event translation. - Enforce the new bridge file and factory import/export conventions via `konsistent.json`. ## End-to-End Verification `examples/harness-e2e-next` for all bridge harnesses was used to verify no behavioral changes occurred - this is purely a code refactoring to improve test coverage. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [ ] 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)

fix(harness): fix harness relay auth (#16432) ## Background Harness host-tool relays passed a bearer token through bridge-managed files and environment, which exposed relay authorization material to the agent runtime. The Codex CLI shim was also written into the session workdir even though it is infrastructure state, not user code. ## Summary This replaces token-bearing relay auth with short-lived, bridge-observed tool-call authorization and bootstrap-process checks for Codex and OpenCode (the only two harnesses using tool relay). - Remove `TOOL_RELAY_TOKEN` and bearer headers from Codex and OpenCode host-tool relays. - Keep Codex's CLI shim in the bootstrap directory instead of the workdir. - Authorize relay requests from observed tool events or known bootstrap helper processes. - Add regression coverage for token-free shims, relay command parsing, one-shot authorization, canonical input matching, and expiry. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [ ] 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)

fix(harness): avoid placing harness bootstrap files in `/tmp` and instead use sandbox working directory (#18294) ## Background MicroVM sandbox providers commonly mount `/tmp` as tmpfs, so bootstrap files stored there are excluded from disk snapshots and therefore cause repeated expensive harness installation processes for every session. ## Summary Bootstrap recipes can now use paths relative to the sandbox's default working directory while existing absolute paths remain supported. - Create each recipe's bootstrap directory in the harness layer and run commands from it by default. - Resolve relative bootstrap, file, and explicit command working-directory paths against the sandbox's default working directory. - Store Claude Code, Codex, DeepAgents, and OpenCode bootstrap assets under `.harness-bootstrap/<id>`. - Update tests, documentation, and the snapshot preparation example for the new behavior. ## Contributor Credit Thanks to @Flo5k5 for the issue report, microsandbox reproduction, and performance measurements. ## End-to-End Verification - Ran `examples/ai-functions/src/harness-agent/prepare-sandbox-for-harness.ts` and confirmed bootstrap assets for all four changed adapters existed before snapshotting and after snapshot restore. - Ran fresh sessions with all bridge harnesses in `examples/harness-e2e-next` and confirmed their bridge runs from the new location. ## 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 #18210

feat(harness): add support for `stopWhen` control to `HarnessAgent` (e.g. `isStepCount(1)`) (#17672) ## Background After #17026 and #17541 laid the foundation for correct per-step emission of the harnesses and step accounting of the harness abstraction layer, the feature of supporting `stopWhen` in `HarnessAgent` is now unblocked. It has been a feature of `ToolLoopAgent` and the underlying `generateText` and `streamText` for a long time, and having it in `HarnessAgent` enables several new patterns. So far, `HarnessAgent` could only run until its current turn stopped naturally, which prevented durable workflows and other callers from pausing cleanly at semantic harness-step boundaries. The only way to use `HarnessAgent` with `workflow` so far was by defining a timeout per step and then interrupting the agent - not as clean of a boundary as one agent step per workflow step. ## Summary This PR adds opt-in `stopWhen` control driven by actual harness `finish-step` events. Matching a condition finishes the current result slice while preserving the unfinished turn for continuation. Omitting `stopWhen` retains the existing run-to-completion behavior - unlike for `ToolLoopAgent`, a default (of let's say 20 steps) does not make as much sense here where the default expectation is that the agent will finish its turn. - Add semantic step accounting and `stopWhen` support to `HarnessAgent`. - Preserve unfinished turns across client-side tools, suspension, and continuation. - Harden adapter step completion and shared bridge replay ordering during interruption. - Add documentation - Add stepped workflow examples in `examples/ai-functions` and `examples/harness-e2e-next` - The formerly called `workflow` examples in the latter were renamed to `workflow-timed`, to clearly distinguish from the new `workflow-stepped` ### Example A single-step-at-a-time agent using the Claude Code harness and Vercel Sandbox: ```ts import { HarnessAgent } from '@ai-sdk/harness/agent'; import { claudeCode } from '@ai-sdk/harness-claude-code'; import { createVercelSandbox } from '@ai-sdk/sandbox-vercel'; import { isStepCount } from 'ai'; export const agent = new HarnessAgent({ harness: claudeCode, sandbox: createVercelSandbox({ runtime: 'node24', ports: [4000], }), stopWhen: isStepCount(1), }); ``` ## End-to-End Verification Run the new examples. ## 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(workflow-harness): introduce workflow utilities for durable harness agent execution (#16315) ## Background After #15919, #15941, and #15969, this is the 4th and final production code breakout PR from #15496. ## Summary This PR introduces `@ai-sdk/workflow-harness`, a package that lets you run a `HarnessAgent` turn in a durable [`workflow`](https://vercel.com/docs/workflow). A long turn is sliced into short, time-boxed steps. Between slices the agent is frozen non-destructively — the sandbox keeps running and the next slice reattaches to the in-flight turn — while a serializable state object is persisted as the durable step return value. The package ships plain, framework-independent helpers plus a serializable state machine; you own the thin `'use workflow'` / `'use step'` wrappers so that Node-heavy dependencies (the agent, sandbox provider) stay out of the compiled workflow bundle. - New `@ai-sdk/workflow-harness` package exposing `createHarnessWorkflowState`, `runHarnessAgentSlice`, and `finalizeHarnessWorkflow`, with the `HarnessWorkflowState` machine that drives slice-by-slice execution and resumption. - Executable examples for the existing harness adapters demonstrating non-destructive turn freezing. - End-to-end workflow examples (route, workflow, and step modules) for each harness in `harness-e2e-next`. - New "Workflow Utilities" documentation page under AI SDK Harnesses. ## Manual Verification Run the workflow examples in `harness-e2e-next` for each harness adapter (Claude Code, Codex, Pi). ## 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)

fix(harness): fix various bugs with harness skills not being correctly processed by the harness adapters (#16051) ## Summary This fixes various skill related bugs in the harness adapters: - Claude Code was not properly receiving custom skills at all, it didn't see them. - Codex was using a horrible workaround where full skill contents were inlined in its instructions (defeating the purpose). - Custom skills generally did not support additional files (i.e. only the `SKILL.md` file). - Writing the custom skills as files into the workspace could be detrimental if that workspace was meant for other files (e.g. a git repo checkout, in which case they would have shown up as an unintended diff). This PR addresses all those problems, in a single consistent way: - All 3 harnesses now write custom skills as files into `$HOME/(.agents|.claude)/skills` inside the sandbox. This works consistently and prevents interferences with the sandbox workspace dir contents. - The Claude Code and Codex primitives are fully relied on, instead of inventing custom solutions that weren't necessary. - The `HarnessV1Skill` type now supports an optional `files` property, and those files are now being written into the sandbox too so the harness adapters can read them as needed. ## Manual Verification Run the `examples/ai-functions/src/harness/*/with-skills.ts` examples or use the interactive `weather` examples in `examples/harness-e2e-next` / `examples/harness-e2e-tui`. ## 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)

tests: fix CI failures in `main` (#16373) ## Background See https://github.com/vercel/ai/actions/runs/28182306242/job/83478014835 ## Summary This PR attempts a fix. ## Checklist <!-- Do not edit this list. Leave items unchecked that don't apply. If you need to track subtasks, create a new "## Tasks" section Please check if the PR fulfills the following requirements: --> - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [ ] 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)

fix(harness): emit `finish-step` stream parts correctly per the underlying model steps (#17026) ## Background Harness adapters were emitting `finish-step` stream parts inconsistently. Deep Agents already had the desired behavior: a step finishes after a tool call/tool result block, or at the end of the turn. All other adapters basically only emitted `finish-step` together with `finish`, defeating that stream part's purpose - a step is part of a turn, not the same as a turn. For simple model calls, a turn may only have one step, but that's uncommon for agent harness tasks. ## Summary - Align `finish-step` emission across Claude Code, Codex, OpenCode, and Pi with Deep Agents semantics. - Add step-tracking helpers for adapters that do not expose their own step-completion concept, so `finish-step` is emitted after completed tool-result blocks and at final turn completion. - Preserve adapter-specific behavior where native step completion exists, including OpenCode legacy `step-finish` handling. - Add harness bridge interruption support and channel interrupt handling so active runs can be interrupted consistently. - Add and update tests for bridge protocol events, OpenCode finish-step behavior, Codex step tracking, Pi translation, and sandbox channel interruption. ## Manual Verification Use the `examples/harness-e2e-next` interactive examples and inspect the network responses for the stream chunks to find them now correctly emitting `finish-step` between e.g. different iterations of tool calls. ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [ ] 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 This is the first step in making `HarnessAgent` step aware. Fixing this in the harness adapters unblocks the more central infra, working towards supporting things like `stopWhen: isStepCount(5)`, or step-based listener callbacks.

feat(harness): allow pre-snapshot `sandboxConfig.onBootstrap` callback in `HarnessAgent` (#16355) ## Background So far, sandbox providers with the ability to create snapshots were only creating the snapshot based on the harness-owned `HarnessV1Bootstrap` recipe. `HarnessAgent` definitions could only run setup logic via `onSandboxSession`, which runs post-snapshot on every session. For costly and slow operations, this is far from ideal for UX. ## Summary This PR adds the ability to define an additional callback that runs pre-snapshot: - `onSandboxSession` is replaced by a `sandboxConfig` object, where it is now available via `sandboxConfig.onSession` - `sandboxConfig.onBootstrap` allows defining the pre-snapshot callback - `sandboxConfig.bootstrapHash` is necessary to specify with `sandboxConfig.onBootstrap` so that the abstraction knows when to use a fresh snapshot rather than looking up an existing one - a minor but related new feature is `sandboxConfig.workDir` allows setting the directory where the agent harness operates in, relative to the sandbox provider's default working directory ## Manual Verification Run the AI SDK Coding examples. The expensive repo checkout now happens in `onBootstrap` instead of `onSession`, making this _a lot_ faster after the first session. ## 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(workflow-harness): add utility functions for agent-step based workflow step definitions (#17999) ## Background #17672 added step control to `HarnessAgent`, but the `workflow-harness` package wasn't updated then. It still only exposed time-based execution slices, requiring consumers who want durable semantic agent-step boundaries to write their own orchestration. ## Summary - Add `runHarnessAgentStep()` for workflows configured with `stopWhen: isStepCount(1)`. - Rename the time-based API to `runHarnessAgentTimeSlice()` and retain `runHarnessAgentSlice()` as a backward-compatible deprecated wrapper. - Use `ready_for_next_step` consistently when an unfinished turn can continue in another workflow step. - Add stepped workflow coverage to the Next.js harness examples and document both approaches with shared resume persistence. - Holistically improve the workflow harness specific documentation for clarity and brevity. ### Example ```ts import { createHarnessWorkflowState, finalizeHarnessWorkflow, runHarnessAgentStep, type HarnessWorkflowInput, type HarnessWorkflowState, } from '@ai-sdk/workflow-harness'; export async function agentWorkflow(input: { messages: NonNullable<HarnessWorkflowInput['messages']>; sessionId: string; }) { 'use workflow'; let state = createHarnessWorkflowState(input); do { state = await agentStep(state); } while (state.status === 'ready_for_next_step'); return finalizeHarnessWorkflow(state); } export async function agentStep( state: HarnessWorkflowState, ): Promise<HarnessWorkflowState> { 'use step'; const { agent } = await import('./stepped-harness-agent'); return runHarnessAgentStep({ agent, state, }); } ``` ## End-to-End Verification Re-tested both agent step based and time slice based `examples/harness-e2e-next` demos. ## 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)

fix(harness): improve opaque sandbox bridge error handling (#17035) ## Background Bridge-based harness failures could originate inside the sandbox and surface to the host only as a generic "An error occurred", leaving even the host / dev server logs without enough context to debug bridge crashes, retries, or sandbox-side errors. ## Summary - Add shared bridge diagnostics utilities for forwarding bridge process output, preserving startup stderr/stdout tails, and logging bridge errors with harness/session prefixes. - Add `emitError` and `emitWarning` to bridge turns so adapters can distinguish terminal errors from non-fatal diagnostics. - Wire Claude Code, Codex, DeepAgents, and OpenCode adapters to use the central diagnostics paths for bridge process streams and error frames. - Treat retry/non-fatal adapter events as warnings while keeping unrecoverable failures as stream errors. ## Manual Verification - Reproduced harness failures in `examples/harness-e2e-next` and verified dev server logs include `[harness:<id>:error]`, `[harness:<id>:warn]`, or bridge stderr details instead of only the generic "An error occurred" stream failure. ## Checklist <!-- Do not edit this list. Leave items unchecked that don't apply. If you need to track subtasks, create a new "## Tasks" section Please check if the PR fulfills the following requirements: --> - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [ ] 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)

fix(harness): guard against invalid resuming a session vs continuing a turn (#16047) ## Summary This PR improves/fixes a few related harness issues: - `HarnessAgent` had a `continueTurn` that was returning a `StreamTextResult`, but it missed the corresponding equivalent that returns a `GenerateTextResult`. This PR replaces the method with `continueStream` and `continueGenerate`. - These methods are responsible for continuing a session where there's a mid-flight suspended/interrupted turn (e.g. due to requesting tool approval, or due to manual suspension via `suspendTurn`). - `HarnessAgent` now more cleanly separates "resume session state" and "continue turn state", with only the latter being able to continue pending tool approvals (because by definition tool approval requests lead to an interrupted turn). - `HarnessAgent` now guards against incorrect method invocation: when a session is resumed with state that indicates that there's a mid-flight turn, calling `stream` or `generate` will error. Accordingly, if the resume state indicates there is no mid-flight turn, calling `continueStream` or `continueGenerate` will error. ## Manual Verification Run the existing examples. ## 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): send `User-Agent` and `x-client-app` headers in harness adapters (#16879) ## Background Harness adapters route AI Gateway traffic through third-party SDKs, so client attribution has to be configured through each harness runtime. This adds consistent versioned attribution for the current harness packages. ## Summary - Adds build-injected `VERSION` exports and versioned client app constants for all harness packages. - Sends `User-Agent` and `x-client-app` for Codex, DeepAgents, and Pi gateway requests. - Uses Claude Code's `CLAUDE_AGENT_SDK_CLIENT_APP` path, and keeps OpenCode to `x-client-app` where `User-Agent` overrides are not honored. - Adds konsistent rules and focused tests for harness version files, exports, constants, and header/env propagation. ## Manual Verification Run basic harness examples in `examples/ai-functions/src/harness`. ## 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)

fix(harness): improve CLI relay tool invocation logic (#17105) ## Summary Improves CLI relay tool invocation logic for the relevant harnesses (Codex and OpenCode). ## Checklist - [x] All commits are signed (PRs with unsigned commits cannot be merged) - [x] Tests have been added / updated (for bug fixes / features) - [ ] 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)

fix(harness-opencode): avoid bridge import from provider-utils and rely on more granular types (#18284) ## Background Like other harness bridges, the OpenCode bridge runs from an isolated sandbox directory where regular package dependencies like `@ai-sdk/provider-utils` are unavailable. #18167 refactored the duplication of `isRecord` calls, including breaking them out of this bridge and therefore importing `isRecord` from `@ai-sdk/provider-utils`, causing the bridge to fail at startup. ## Summary - Replace the runtime `provider-utils` dependency with a local OpenCode boundary model. - Normalize legacy event, tool, step, and usage payloads before translating them. - Add regression coverage for malformed envelopes and legacy payloads. ## End-to-End Verification Ran OpenCode harness e2e examples 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) - [ ] 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 tooling to prevent import of those kinds of dependencies in bridge code, so it would get flagged before merge in the future.