Felix Arntz

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)

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)

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)

feat(provider/anthropic): add support for `claude-fable-5` and the `fallbacks` API parameter (#15928) ## Summary Anthropic published `claude-fable-5` in the API, including support for a new related `fallbacks` parameter. This PR adds support, examples, and docs for these. ## Manual 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(harness): add utility functions for certain duplicated layers in harnesses (#16531) ## Background Several harness adapters duplicated the same sandbox utility logic for resolving `$HOME`, shell quoting paths, and writing skill files. Keeping those copies in sync made small behavior changes harder and increased the chance of adapter drift. These behaviors are reasonable to abstract away, as they're self-contained and not subject to change, nor very harness specific. ## Summary - Added shared harness utilities for shell quoting, sandbox home directory resolution, and skill file materialization. - Updated Claude Code, Codex, DeepAgents, OpenCode, and Pi harnesses to use the shared utilities while preserving adapter-specific validation/error messages. - Kept bridge-side Zod schema conversion adapter-local so `harness/bridge` does not introduce a shared Zod bridge entrypoint. - Added focused unit coverage for the new utility behavior and updated harness skill tests. ## Manual Verification Run the harness examples. ## 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)

feat(provider/google): support cancelling long-running Interactions API agents via AbortSignal, and process their intermittent stream (#15139) ## Background PR #15013 added Interactions API support but two background-mode gaps remained: aborting a call didn't stop the run on Google's side (kept billing), and `streamText` against an agent buffered everything until the run finished instead of actually streaming. ## Summary - Poll loop now fires `POST /interactions/{id}/cancel` on abort. - Agent `doStream` now opens `GET /interactions/{id}?stream=true` and reconnects with `last_event_id` on idle disconnects. - Existing `streamText` agent examples switched to `fullStream` with dimmed `reasoning-delta` output; new abort examples + shared SIGINT→AbortController helper. ## Manual Verification - `aif examples/ai-functions/src/stream-text/google/interactions-agent-single-turn.ts` — reasoning prints incrementally. - `aif examples/ai-functions/src/generate-text/google/interactions-agent-abort.ts` — server-reported status flips to `cancelled`. ## 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 - `webhook_config` — deferred until the AI SDK has a fire-and-forget primitive; polling alongside a webhook defeats the point. - `background: true` for model-id calls — API rejects every documented model today, it seems the API only supports this parameter in combination with `agent`.

fix(harness): make listening for sandbox bridge readiness compatible with Bun (#16069) ## Summary Bun can miss `stdout` from detached sandbox bridge processes that bind an exposed port, so Claude Code/Codex startup timed out waiting for `bridge-ready` even though the bridge was running. This PR adds a shared harness readiness helper that keeps `stdout` as the primary signal (for non-Bun), falls back to the bridge metadata file, and marks startup state to avoid stale metadata on respawn. ## 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)